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SUMMARY 


This  -•eport  consists  of  two  volumes:  In  Volume  1,  the  Integrated  Analysis 
Techniques  (lAT)  for  Command,  Control  and  Communications  (C3)  systems,  are 
described,  along  with  the  background,  concept,  requisite  methodologies,  and 
recomtaendat ions  tor  an  automated  analyst's  aid.  In  Volume  II,  the  evolution 
of  IAT  via  successive  trial  applications  to  three  (C3)  systems  is  described 
and  the  lessons  learned  are  summarized. 


This  second  volume  describes  in  detail  the  trial  applications  of  the  IAT 
methodology  in  various  stages  of  Its  development  to  three  command  and  control- 
related  systems: 


SlMCOPE,  a  simulated  C3  subsystem  resident  at  AAMRL; 


the  NORAD  Missile  Warning  Center;  and 


a  generic  air  defense  system. 


From  each  application,  certain  important  lessons  were  learned  and  applied  in 
each  succeeding  application,  ••esulting  in  the  evolution  of  IAT  as  described 
in  Volume  1. 


Both  IDEF0  and  Data  Flow  Diagrams  were  used  in  these  trial  applications, 
and  both  PERT/CPM  and  queuing  analyses  were  used  to  model  the  C3  process 
descriptions.  The  lessons  learned  from  these  applications  are  summarized  at 
the  end  of  this  Volume.  Analysis  details  and  guidelines  for  using  the  various 
descriptive  methods  are  included  in  Appendices. 
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PREFACE 
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Integration  Technology. 
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In  addition  to  those  Individuals  mentioned  above,  the  authors  would 
like  to  thank  Mr.  James  C.  Deckert  and  Dr.  Nils  R.  Sandell,  Jr.  of  ALPHATECH, 
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SECTION  1 


INTRODUCTION 


This  volume  describes  in  detail  the  trial  applications  of  the  IAT  meth¬ 
odology  in  various  stages  of  its  development  to  three  command  and  control- 
related  systems: 

SIMCOPE,  a  simulated  C3  subsystem  resident  at  AAMRL; 

-  the  NORAD  Missile  Warning  Center;  and 
a  generic  air  defense  system. 

From  each  application,  certain  important  lessons  were  learned  and  applied  in 
each  succeeding  application,  resulting  in  the  evolution  of  IAT  as  described 
in  Volume  I. 

Both  IDEF0  and  Data  Flow  Diagrams  were  used  in  these  trial  applications, 
and  both  PERT/CPM  and  queuing  analyses  were  used  to  model  the  C3  process 
descriptions.  The  lessons  learned  from  these  applications  are  summarized  at 
the  end  of  this  Volume.  Analysis  details  and  guidelines  for  using  the  various 
descriptive  methods  are  included  in  Appendices. 
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SECTION  2 

SIMCQPE  APPLICATION 


The  SIMCOPE  facility  at  AAHRL  was  chosen  as  a  test  case  for  illustrating 
"he  application  of  preliminary  IAT  methods.  SIMCOPE  was  selected  for  several 
reasons : 

1.  It  approximates  the  complexity  of  a  node  in  real-world  manned 
C3  systems  like  those  at  NORAD  MUC  (even  though  its  scenarios 
are  fictitious). 

2.  Its  operations  are  neatly  circumscribed. 

3.  It  permits  the  study  of  human  performance  within  a  controlled 
laboratory  environment  (that  approximates  a  real-world  opera¬ 
tional  setting). 

4.  The  details  of  its  design  and  operation  can  be  analyzed  and 
discussed  openly  (because  of  its  fictitious  nature). 

The  focus  of  SIMCOPE  is  on  the  Missile  Warning  Officer  (MWO) ,  whose  main  role 
is  to  monitor  data  to  detect  missile  launches  that  may  pose  a  possible  threat. 
Performance  predictions  relevant  for  the  validation  address  questions  of  sys¬ 
tem  throughput  —  e.g.,  what  happens  as  input  message  arrivals  exceed  operator 
service  rates?  what  operating  strategies  best  handle  the  work  backlog?  are 
there  alternative  designs  that  can  alleviate  the  bottleneck? 

For  using  SIMCOPE  as  a  case  study  to  validate  IAT  methods,  several  nota- 
t^onal  formats  were  required.  These  are  reviewed  in  the  sections  that  follow. 


2.1  OPERATOR  SCENARIOS 

These  specify  the  tasks  and  task  sequences  that  MWOs  would  perform  to 
carry  out  their  responsibilities  in  a  MWC.  Subject  instructions  were  devel¬ 
oped  under  the  AAMRL  COPE  Program  for  this  purpose,  and  are  described  in 
ALPHASCIENCE  (1984). 


2.2  DATA  FLOWS  (DeMarco) 

Because  analytic  methods  like  queuing  theory  require  explicit  information 
about  da_t_a^  fl_ow,  a  formalism  was  needed  that  would  capture  this  information  in 
SIMCOPE.  Of  critical  interest  are  the  following  data  flow  characteristics: 
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•  Data  Stores:  sites,  temporary  repositories  of  data  (e.g., 
computer"  files,  blackboards,  operator  displays). 

•  Sources :  points  of  origin. 

•  Sinks :  points  of  destination. 

•  Processes :  transformations  that  map  input  data  to  output  data. 

•  Flows :  "pipelines"  through  which  packets  of  information  of 
known  composition  may  flow. 

DeMarco  data  flow  diagrams  (DeMarco,  1978)  provide  a  simple  syntax  and  seman¬ 
tics  for  capturing  these  characteristics.  Figure  2-1  describes  thu  i_uirponents 
of  a  DeMarco  diagram;  Fig.  2-2  presents  an  example  of  how  these  diagrams  were 
used  to  portray  data  flow  in  SIMCOPE.  (Detailed  discussion  and  explication  of 
the  SIMCOPE  example  can  be  found  in  subsections  2.4  and  2.5,  and  Appendix  E. 
Table  2-1  lists  abbreviations  and  acronyms  used  in  SIMCOPE.) 


SOURCE 


COMPONENTS 


1.  Data  flows,  represented  by  labeled  arrows;  (X,Y,Z) 

2.  Processes,  represented  by  circles;  (P^^) 

3.  Files  or  Data  Stores,  represented  by  straight  lines;  FILE 

4.  Data  Sources  or  Sinks,  represented  by  boxes. 


Figure  2-1.  DeMarco  Data  Flow  Diagram  (Example) 


Figure  2-2a.  DeMarco  Diagram  Used  in  SIMCOPE  Validation:  Context 


FILE 


Figure  2-2b.  DeMarco  Diagram  Used  in  SIMCOPE  Validation:  Overall  Data  Flow 


TABLE  2-1.  LIST  OF  ABBREVIATIONS  AND  ACRONYMS  USED  IN  SIMCOPE  EXAMPLE 


_ _ _ 

ADS-1 

ADS-2 

ADS-N 

ADS-S 

AGS  or 
ADS-GSF 

BGS  or 
BSS-GSF 

BSS 

BURF  or 
BRF 

CDC 

CWC 

INT 

MWO 

SYS 

ACKNOWL 
ASSIGN 
BACKSTEP 


ADS  Pass  1  Message 
ADS  Pass  2  Message 
Advanced  Detection  System-North 
Advanced  Detection  System-South 

ADS  Ground  Support  (Facility) 

BSS  Ground  Support  (Facility) 

Barrier  Surveillance  System 

Back-Up  Routing  Facility 
Command  Defense  Center 
Command  Warning  Center 
Intelligence  Messages 
Missile  Warning  Officer 
System  Status  Messages 

Acknowledge  )  Names  of  Function  Keys 

(  on  Operator  Touchscreen 


AUTO 

EDIT 


Names  of  Mode  Controls  on 
Operator  Touchscreen 


2.3  USE  OF  FRAME  NOTATION 


Frames  were  used  Co  detail  aspects  of  information  captured  in  the  data 
flow  diagrams.  This  was  done  to  facilitate  cross-referencing  of  data  elements 
and  provide  traceability  from  data  and  processes  (shown  in  DeMarco  diagrams) 
back  to  components  of  system  structure  (COALS,  ORGANIZATIONS,  PROCESSES, 
RESOURCES).  Figure  2-3  is  an  example  of  a  PROCESS  Frame  for  the  process 
called  "Monitor  for  Enemy  Missile  Launch"  In  the  SLMCOPE  context;  Fig.  2-4 
shows  the  hierarchical  decomposition  in  terms  of  system  structure. 


PROCESS  HAKE: 
COAL: 


MONITOR  FOR  ENEMY  MISSILE  LAUNCH 
TO  ADVISE  COC  OP  A  SUSPECTED  ATTACK 


ORGANIZATIONAL  ELEMENT:  MISSILE  WARN  INC  OFFICER  (KUO)  ...  prlaary  raapona  Ibl  1  It  r 
ACTING  DUTY  OFFICER  (ADO)  ...  4«li|U«d  raaponalblllty 


PARENT  PROCESS: 
SUB-PROCESSES  REQUIRED! 

INPUTS  REQUIRED: 


1)  ACKNOWLEDGE  MESSAGE 

2)  ASSIGN  EVENT  NUMBER 

3)  CINE RATE  EVENT  REPORTS 

HESSACES  -  (A  TYPES) 

1)  INTELLIGENCE 

2)  STSTEM  STATUS 
))  ADS 

A)  BSS 

EVENT  REPORTS  -  (J) 


1)  ADS1 

2)  ADS2 
1)  BSS 

MEASURES  OF  PERFORMANCE:  TIMELINESS 
ACCURACY 


RESOURCES  REQUIRED: 


MVO  CONSOLE 

STAFF  ASSICNED  TO  KUO/ADO  DUTIES 


Figure  2-3.  Example  of  IAT  Structural  Description  and  Process  Frame  for  the 
Process  "Monitor  for  Enemy  Missile  Launch"  (Kornfeld,  1984) 
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Figure  2-4.  Monitor  for  Enemy  Missile  Launch:  Tree  Structure  Hierarchy 


2.4  QUEUING  REPRESENTATION 


Describing  information  about  system  structure  and  behavior  with  t he 
formalisms  discussed  above  made  it  possible  to  construct  a  queuing  represen¬ 
tation  of  SIMCOPE .  This  was  a  straightforward  process  to  the  extent  that  the 
data  flow  and  frame  analyses  revealed  specific  properties  of  system  behavior 
that  could  be  captured  in  a  queuing  model;  viz.,  SIMCOPE  was  seen  to  be: 

•  highly  buffered  (i.e.,  processes  were  not  directly  linked 
but  were  mediated  by  queues  and  file-stores), 

•  characterized  in  terms  of  message-handling,  storage ,  and 
updating  processes. 


2.4.1  Identifying  Further  Information  About  System  Behavior 

Figure  2-2a  provides  the  context  for  further  modeling  of  SIMCOPE  using 
queuing  theory  approaches.  This  context  diagram  makes  explicit  the  various 
messages  that  are  routed  to  the  Command  Defense  Center  (CDC). 

Figure  2-2b  describes  the  system  at  a  high  level  from  the  perspective 
of  information  flow.  Four  processes  are  identified:  Numbers  1-3  correspond 
co  the  three  main  functions  of  the  system  (Acknowledge  Messages,  Assign 
Event-Related  Data,  Generate  Reports);  Number  4  describes  background  updating 
activities  (processing  carried  out  to  keep  current  on  intelligence  and  status 
information).  Only  Numbers  1-3  are  considered  in  sufficient  detail  for 
building  a  queuing  model  of  the  entire  system. 

Figures  2-5,  2-6,  and  2-7  show  the  decompositions  of  SIMCOPE  functions, 
Numbers  1-3,  which  were  introduced  at  the  highest  level  in  Fig.  2-2b. 


2.4.2  Insights  Obtained  From  Data  Flow  Analyses 

Figures  2-5  through  2-7  make  clear  the  general  flow  of  activities  (mes¬ 
sage  processing)  and  allow  investigators  to  examine  the  performance  of  human 
agents  within  the  system  as  a  whole.  In  particular: 

•  Operator  displays  function  as  data  stores  with  respect  to 
message  processing. 

•  Operators  directly  implement  processes  Number  1.3  ("Acknowledge 
Message"),  Number  2.2  ("Generate  Response"),  Number  3.2 
("Select  Event"),  and  Number  3.3  ("Select  Data  Item");  processes 
other  than  those  listed  here  are  implemented  by  computer. 

The  above-named  processes  are  the  primitives  of  operator  tasking  in  SIMCOPE; 
any  further  decomposition  of  human  operator  activity  would  yield  only  proce¬ 
dural  information  and  not  data  flow.  The  methodology  used  to  analyze  these 
processes  has  thus  provided  both  insight  into  human/system  behavior  and  has 
at  the  same  time  helped  set  a  practical  limit  to  further  decomposition. 
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Figure  2-7.  The  Data  Flow  Diagram  for  the  Generate  Report  Process 


2.4.3  Constructing  the  Queuing  Representation 

The  information  displayed  in  Figs.  2-2  through  2-7  was  used  to  derive  a 
queuing  representation  for  SIMCOPE,  as  presented  in  Fig.  2-8.  This  represen¬ 
tation  is  comprised  of  the  following  elements: 

1.  Input  source,  with  messages  ("Equipment  Status,”  "Intelligence," 
and  "Suspected  Launch  Events"). 

2.  A  single  server  (merged  from  processes  1-3,  shown  in  Fig.  2-2b). 
(The  service  facility  is  located  in  the  Command  Warning 
Center,  CWC.) 

3.  Two  output  channels  ("Equipment  Status"  and  "Intelligence 
Reports" ) . 

Two  feedback  channels  (from  the  "Report"  and  "Assign"  queues 
back  to  the  CWC). 


4. 
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Figure  2-8.  The  Queuing  Representation  of  SlMCOPE 


2.5  THE  QUEUING  MODEL 
2.5.1  Methodology 

The  following  method  was  used  to  construct  the  queuing  model  for  SIMCOPK : 

1.  Use  information  derived  from  operator  scenarios  (ALPHASCIENCK, 

1934),  data  flows,  and  frames  to  characterize  message  handling 
and  processing  —  these  activities  determine  the  demand  for 
human  and  computer  resources  within  the  S1MC(  ’E  operational 

e  nvironment . 

2.  Derive  a  quantitative  description  of  resource  demands  associated 
with  workloads,  where  SIMCOPE  workloads  are  defined  by  the  type, 
number,  and  sequence  of  messages  that  require  processing. 

3.  Select  components  of  workloads  to  be  characterized.  Human 
operator  tasks  and  task  procedures  provide  a  meaningful  basis 
for  identifying  these  components,  insofar  as  task  performance 
can  be  associated  with  specific  triggering/stopping  events 
(''activations"  and  "terminations")  and  completion  times- 

4.  Select  features  (parameters)  for  characterizing  each  component. 

5.  Use  data  available  from  the  operational  environment  via 

( ALPHASC1ENCE ,  1984)  and  from  published  sources  on  human  per¬ 
formance  (Woodson,  1981)  to  obtain  the  feature  or  parameter 
values  for  each  component.* 

*In  real-world  systems,  rathei  than  in  simulated  environments  such  as  SIMCOPE, 
this  step  would  constitute  workload  measurement.  Data  would  be  collected 
while  the  system  is  executing.  Repeated  measurements  over  time  could  yield 
a  large  collection  of  multivariate  data;  exploratory  data  analysis  could  then 
proceed,  and  empirical  distributions  and  sample  moments  of  each  of  the  param¬ 
eters  might  be  obtained  (Heidelberger  and  Lavenberg,  1984;  Kobayashi ,  1978). 
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Appendix  A  describes  in  detail  bow  these  procedures  were  followed  to 
derive  quantitative  information  about  human  and  system  performance  in  SIMCOPE. 
For  the  SIMCOPE  case,  in  particular,  it  was  necessary  to  carry  out  the  steps 
listed  below  to  character ize  workloads  in  a  manner  appropriate  for  obtaining 
numerical  data: 

•  Identify  "scenario-drivers"  --  these  are  factors  or  events 
external  to  the  system  being  analyzed  that  act  as  activators 

or  terminators  of  specific  processes  in  the  model.  For  SIMCOPE, 
the  overall  scenario  driving  the  system  was  described  in  frames 
and  tree  structure  notation  to  show  mission  events  and  their 
impact  on  human  operator  workload  and  task  performance. 

•  State  assumptions  and  describe  structure  of  the  queuing  model  — 
viz.,  characterize  message  stream,  processors,  and  their  asso¬ 
ciated  properties  within  the  S1MC0PE  context. 

•  Develop  notations  and  expressions  for  arrival  and  service  rates 
of  interest. 

•  Derive  expressions  to  describe  waiting  times. 


Estimate  delays  and  queue  lengths. 


Determine  service  rates  ("effective  rates,”  given  that  the  same 
resource  must  be  used  in  several  processes;  and  task-specific 
rates,  for  cases  in  which  resource  attention  is  devoted  to  a 
particular  task). 


2.5.2  Quan t 1 1 a t i v e  Results  and  Their  Imp  1 icat ions 
Workload  and  Capacity 

Since  the  workload  imposed  on  human  operators  is  a  critical  factor  in 
allocating  tasks  in  manned  C3  systems,  the  quantitative  estimates  and  char¬ 
acterization  of  workload  in  SIMCOPE  should  be  viewed  as  significant  inputs 
for  improving  human  and  system  performance.  As  part  of  the  queuing  theory 
approach  to  modeling  SIMCOPE,  the  following  features  were  analyzed  and  their 
associated  values  obtained: 

1.  Time  required  for  performing  single  tasks  and  a  series  of  tasks. 

2.  Extent  to  which  operators  were  (assumed  to  be)  mentally  or 
physically  busy. 

3.  Rates  for  making  decisions  and  processing  information. 

Determining  values  for  these  human  (operator)-oriented  measures  provides 
analysts  and  planners  with  information  they  need  to  examine  system-  or 
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installation-oriented  incisures  such  .is  throughput  and  utilisation,  both  ol 
which  can  indicate  the  efficiency,  or  degree  of  productivity,  a  system 
provides. 

Redesign  Issues 

Managing  existing  systems  efficiently  and  planning  adequately  1  * > r  tuture 
systeias  requires  that  the  following  be  done: 

1.  Identify  current  performance  problems  and  correct  then  («•..., 
by  load  shedding  or  workload  balancing,). 

2.  Identify  potential  future  performance  problems  and  prevent  them 
(e.g.,  by  upgrading  system  resources  in  a  t  '  me  1  y  manner). 

The  modeling  work  presented  in  Appendix  A,  subsections  and  A-b,  yields 

results  relevant  to  both  of  Che  tasks  mentioned  above.  In  particular,  system 
bottlenecks  were  identified  for  the  SlMCOPt  environment  (e.g.,  acknowledging 
audio-cued  arriving  messages).* 

Using  queuing  analysis  techniques  to  identify  bottlenecks  becomes  useful 
to  supervisors  and  planners  because  it  could  allow  them  to  explore  effects 
of  changing  particular  types  of  input  (e.g.  ,  audio-cued  arriving  messages  as 
opposed  to  non-cued)  on  specific  tasks  facing  human  operators  (acknowledge ng 
certain  kinds  of  messages). 

Potential  benefits  of  adding  one  or  more  operators  iould  also  be  exam¬ 
ined,  given  the  analysis  in  Appendix  A,  subsections  A.). 2  -  A-4,  by  adjusting 
the  appropriate  service  time  parameters. 

Finally,  the  close  analysis  of  operator  touts  required  for  the  SIMCOPt 
modeling  revealed  the t  the  CRT  display  design  directly  affected  service  times 
The  display  could  be  redesigned  to  facilitate  human  performance  in  scanning 
tasks  (e.g.,  using  reverse  video,  blinking,  or  other  visual  contrasts  to  high 
light  events  under  cons "deration,  and  thereby  reduce  effective  search  lime). 


*By  "bottleneck,"  we  refer  to  a  resource  or  service  facility  whose  capacity 
seriously  limits  the  performance  of  an  entire  system.  A  bottleneck  is 
created  at  some  resource  when  the  job  traffic  ("workload")  to  that  resource 
approaches  the  resource  capacity  (the  resource  is  "saturated"  and  the  level 
of  congestion  increases  (Kobayashi  ,  1V78)). 


SECTION  3 


APPLICATION  OF  IAT  TO  NORAD  CMC  MWC/CP 


In  this  section  the  results  of  the  application  of  the  IAT  methodology  to 
the  NORAD  Cheyenne  Mountain  Complex  (CMC)  Missile  Warning  Center  (MWC)  and 
Command  Post  (CP)  are  presented.  (Appendix  B  lists  acronyms  used  in  this 
section.)  The  direction  of  this  activity  was  focused  on  the  interactions 
between  the  MWC  and  CP  in  response  to  a  Submarine-Launched  Ballistic  Missile 
( SLBM)  scenario.* 


3.1  FIELD  DATA  COLLECTION 

Information  derived  from  the  literature  was  supplemented  by  the  following 
sources : 

1.  Discussion  with  MWC  operations  personnel  (D01M/J31M),  by  tele¬ 
phone  and  in  person,  to  obtain  answers  to  questions  listed  in 
Table  3-7. 

2.  Task  Description  Worksheets  (TDWs)  describing  MWC  duties,  sup¬ 
plied  by  the  Training  Development  Division  (D0TT/J3TT),  Direc¬ 
torate  of  Training,  Standards,  and  Evaluation  (D0T/J3T).  These 
TDWs  are  part  of  the  documentation  now  in  progress  to  upgrade 
training  materials  (to  support  an  Instructional  Systems  Design 
(ISD)  approach  to  training  program  development). 

3.  SLBM  scenario,  used  by  Command  Post  Training  Branch  (D01T0C/ 

J31T0C),  Directorate  of  Training  and  Exercise  (D01T/J31T). 

MWC/CP  crew  members  carried  out  a  structured  walkthrough  of 
MWC/CP  activities,  based  on  this  scenario  and  explained  proce¬ 
dures  used  in  the  MWC  to  analyze  sensor  data  and  assess  threats. 

4.  Observations  of  MWC/CP  crew,  hosted  by  Directorate  of  Missile 
Warning  Operations  (D01M/J3SM)  and  Missile  Warning  Training 
Branch  (D01T0M/J 31T0M) .  Crew  members  were  observed  and  inter¬ 
viewed  informally  during  the  following  conditions:  day-to-day 
(routine)  operations,  involving  equipment  maintenance,  logging, 
etc.;  crew  change,  including  preparation  and  delivery  of  brief¬ 
ings;  SLBM  exercise,  mirroring  activities  described  in  the 
training  scenario. 

*M.  Vfkmanis,  private  communication  to  G.P.  Chubb,  4  January  1985. 


The  information  collected  first-hand  from  the  sources  named  above  was 
consistent  with  MWC/CP  mission  and  major  functions,  as  described  from  the 
AAMRL  literature.  Discrepancies  were  in  general  due  to  equipment  upgrades, 
change  in  crew  position  names,  and  facilities  arrangements* **. 


3.2  SCOPE  OF  THE  MODELING 

Boundaries  of  the  validation  analysis  were  established  as: 

INPUT  BOUNDARY  -  messages  coming  into  MWC  for  processing, 

OUTPUT  BOUNDARY  -  dissemination  of  TW/AA  reports  to  specified 
subscribers,  called  "Forward  Users." 

Figure  3-1  shows  the  scope  of  the  analysis.  Figure  3-2  presents  a  detail  of 
CP  configuration,  highlighting  crew  position  roles  that  figure  in  the  SLBM 
scenario. 
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Figure  3-1.  High-Level  View  of  MWC/CP  Operations* 

*MWC  and  SPACE  were  formerly  co-located  in  the  CMC. 

**Wide  arrows  indicate  the  scope  of  the  validation  analysis. 
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Figure  3-2.  Command  Pose  (CP)  Organization 
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3 . 3  STRUCTURAL  MODEL 


The  SLBM  scenario  served  as  the  basis  for  constructing  DeMarco  data  flow 
diagrams  (DFDs)  and  more  detailed  flow  chart  models  of  human  operator  and 
system  performance.  The  results  of  this  modeling  are  summarized  in  Figs.  3-3 
through  3-11.  Explanatory  notes  and  descriptions  of  human  operator  tasks  and 
subtasks  are  provided  in  Appendix  C,  where  specific  TDWs  are  cross-referenced 
to  activities  shown  in  the  flow  charts.  Appendix  D  presents  a  preliminary  set 
of  ORGANIZATION  frames  for  the  MWC/CP. 


3 . 4  PERFORMANCE  MODEL 

The  purpose  of  this  activity  is  to  convert  the  descriptive  and  structural 
data  provided  via  the  data  flow  diagrams,  flow  charts,  and  other  notes  and 
training  documents  into  a  quantitative  model  suitable  for  assessing  perfor¬ 
mance.  The  primary  dimensions  of  concern  are  timelines  (or  delay  or  through¬ 
put)  and  resource  utilization.  Earlier  work  on  IAT  used  queuing  network 
models  and  associated  analysis  techniques  for  this  purpose.  As  will  be  argued 
shortly,  the  MWC/CP  system  is  designed  and  staffed  in  such  a  way  that  there 
is  very  little  queuing  in  the  traditional  sense  of  the  term.  Problems  of  slow 
response  or  delay  may  well  exist,  but  they  can  be  accounted  for  with  simpler 
procedures.  The  structural  reasons  for  these  conclusions,  as  well  as  illu¬ 
strations  of  the  performance  modeling,  are  developed  below. 


3.4.1  Scope 

The  f ocus  of  the  analysis  is  on  the  MWC,  the  CP,  and  their  interactions. 
The  primary  processes  data  flow  diagram  (Level  0),  Fig.  3-5  shows  six  major 
processes.  One  of  these,  process  1,  "Monitor  Data  and  Recognize  Event 
Messages,"  is  performed  at  the  various  sensor  sites.  This  process,  there¬ 
fore,  will  not  be  directly  considered  in  this  analysis.  The  remaining  five 
processes  are  carried  out  jointly  by  the  CP  and  MWC.  Process  6,  "Log  System 
Status  and  Event  Data,"  is  a  routine  function  executed  after  the  time-critical 
activities  are  completed.  For  this  reason,  and  for  reasons  of  maintaining 
simplicity,  this  process  also  will  not  be  considered.  The  modeling,  there¬ 
fore,  will  focus  on  the  four  processes  starting  with  the  verification  of  event 
reports  and  ending  with  TW/AA  messages  being  sent. 


3.4.2  Formulation  of  a  Modeling  Approach 

Following  the  same  approach  that  was  used  with  the  SIMC0PE  example  in 
Section  2,  the  decomposed  data  flow  diagrams  were  analyzed  for  indications  of 
congestion  or  queuing.  The  decompositions  of  processes  2,  3,  and  5  shown  in 
Figs.  3-7,  3-8,  and  3-9  all  reveal  numerous  data  stores.  With  the  possible 
exception  of  the  "Formatted  Messages"  store  shown  on  Figure  3-9,  there  is  no 
indication  of  a  collection  or  backlog  of  work  requiring  processing.  By  and 
large,  the  data  stores  displayed  on  these  diagrams  consist  either  of  short¬ 
term  "working  memory"  types  of  data  or  archival  records.  They  constitute 
information  available  for  use  rather  than  work  in  need  of  processing. 


•mm-mmmv  \n%  tflUHVVlVWW.N  W7 /'JfWIW'W  WUHinH  KV  njrn» 


STANDARD  CONVENTIONS: 


A  directed  line  represents  a  flow  of  information  or 
objects.  The  arrow  indicates  the  direction  of  the 
data  flow.  The  name  of  the  data  flow  is  written 
through  or  next  to  the  line. 


A  circle  represents  a  task  or  process.  It  identifies 
a  transformation  of  input  data  flows  into  output  data 
flows.  A  brief  descriptive  name  and  a  reference  num¬ 
ber  for  the  process  are  written  inside  the  circle. 


Two  parallel  lines  represent  a  store  of  information 
or  objects,  irrespective  of  the  storage  medium.  The 
store  identifies  a  time  delay  for  its  contents.  The 
name  of  the  store  is  written  between  the  lines. 


A  rectangle  represents  an  area  where  data  originates 
or  terminates  from  the  point  of  view  of  the  system 
study.  It  identifies  a  boundary  of  the  system  study; 
the  identification  of  the  originator /terminator  is 
written  inside  the  box.  Termed  "source”  or  "sink." 


NON-STANDARD  CONVENTIONS: 


A  dashed  circle  represents  a  process  which  takes 
place  outside  of  the  Center.  No  further  breakdowns 
are  presented. 


A  dashed  box  represents  a  source  or  sink  outside  of 
the  Center. 


A  dashed  arrow  represents  data  being  passed  outside 
of  the  Center. 


Figure  3-3.  Notes  for  Data  Flow  Diagrams 
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Figure  3-6.  Processing  Sensor  Data:  Data  Flow  Between  Ground-Based 
Stations  and  NORAD  CMC  (Level  1) 
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Figure  3-7.  Processing  Event  Reports:  MWC  Activities  (Level  2) 
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Figure  3-8.  Developing  Current  Situation  Description  (CSD)  and  Obtaining 
CINCNORAD  Assessments:  CP  Data  Flow  (Level  3) 
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Figure  3-10.  Notes  for  Flow  Charts 
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Figure  3-11.  Flow  Charts  for  MWC/CP  Response  to  SLBM  from  Quick  Look  Area 


vvvjyv y„> vy  A.v.'.v 


■  V*  . 


h 


V?t 


PROCESSING  EUEHT  REPORTS:  nUC/CP  OPERRTIONS 


pc-Ljof-L 


me. ALL  2.1 

E> 

j  MOM  IT  OR  | 

*  NCS  • _ 

T 

kTeN 

PANELS  j 

3  6 

MWT2  ^  _  2.7 

EUO  2. a 

EUO 

2.0 

TUWET 
PRINTER  2.10 

■ReouEsf"- 
CONFIRnATION 
OF  EUENT 
MESSAGE 


SECURE 
-  UOICE 
LINK 


RECEIUE 
REQUEST  FOR 
CONF I  RflRT  I  ON 


t<_1  a  in 
■y 


ISSUE 

SYSTEM 

REPORT 


rwc  ]  2.25 
RECEIUE: 

.  RDOITIONRL  \a 
OflTfl  FROM 
SENSOR  SITE: 


SS  2.  16 

CONFIRM 
.  EUEMT 
'  MESSRGE  OUEB  ' 
UOICE  LINK 


RECEIUE 

SYSTEM 

REPORT 


INITIATE  - 
BEIGE  LOOP  : 
CONFERENCE  1 


:"b§Y6Tii"fR6'": 

JOATA  FROM  NCS: . 
:  t  LOCATION 
WTfl  FROM  ruoi 


'W  2.10 

./is"*-.,. 

/  EUENT  XVES 
...  URL  10  ,/ 

w 


EUO  2.20 

i  *URL 10* 

;  OMER  8EI0E 

:  loop 


(FALSE  OR  PENDING 
INVESTIGATION) 


EUO  ^-2.26 

/""brief . : 

_ ; INFORMATION  i 

;  TO  CO  OUER  : 

:  BEIGE  LOOP  : 

. [false' 

r*JC  2.20 

rmff/our": 

; PROCEDURES  ON  ; 

■ "FALSE  EUENT"  ; 

:  CHECKLIST ; 

<SEE  NOTE  ON  LEGEND) 


✓  TRANSMIT  ✓ 
/DETAILS  ON/ 
/  LAUNCHES  ^ 

. . r . ' 

EUO  -X.2.12 

: . mr . : 

.'COORDINATES : 

“ ’  on  : 

;  URLLBORROS  | 


| RECEIUE  MUCJ 
f  BRIEFING  i 
J  ON  EUENT  $ 


r«T|  - 

MUT2  ,X, 2.30 

'-mtu . v 

.  "UAL  ID"  ' 

'  ON  NCS,  / 
NEBU  ' 


CO  2.2? 

t DIRECTIONS  TO  , 
ENTER  "URL  10*  • 


un  ntd 

0  -Jp.  2.32 

'  NON  I  TOR" 
NCS,  PANELS  / 


to 

h 


Ks 


HI 


DEVELOP  I  MG  CSO  and  OBTHIMHG  C  I  HCMORflD  RSSESSflEMTS 

<CONTINU£D> 


% 

I 

ft 


SENDING  TU/flfl  MESSAGES :  HUC  ORTfl  FLOU 

<CONT I NJEO  > 


PC_— OF_I 


CO  4.  II 

jWtjugiMMUMgMW'XW^Jv; 

I  REQUEST  J 
C  CINC  | 
f  assessment^! 


IWW>JWWWJ 

RECEIVE 
CINC  a 


ASSESSMENT^ 

SV  V.  WA'A'lVV'lVyV 


HH 


CINC  4.12 

W  ■*W>  '•P  *>*  S’*  •»/•*  JW 

I  RECEIUE  I 
K  ASSESSMENT  5 
|  REQUEST  2e 

v  v.  '"W' ■ 

CINC  *^Lr  4.  14 

tnwKraeni 

J  ASSESSMENT  J 

j  <sftrc  or 

;■  H I  CHER  >  * 


CONTINUOUS 
LOGGING  OT 
EVENT-RELATED 
INFORMATION 
DONE  BV  RO 


# 

l 

I 

I 

% 

«l| 

| 

ft.1 


RS 


8 


|u»» 

1% 


‘.V, 
vV, 
•  *-» 


The  "Formatted  Messages"  file  could  be  an  exception  if  it  contains  a 
set  of  messages  awaiting  service  by  "Send  TW/AA  Messages."  The  Send  TW/AA 
Messages  process  (process  5.2)  is  apparently  an  automated  process,  so  this 
queue  does  not  influence  human  performance,  although  it  might,  have  some  small 
impact  on  overall  system  throughput. 

Since  the  data  flow  diagrams  provided  no  evidence  of  buffering  built 
into  the  system  to  accommodate  congestion,  the  flow  charts  were  analyzed  for 
insights  into  bottlenecks  and/or  timeliness  problems  i.e.,  examined  for  crit¬ 
ical  paths.  Recall  that  data  flow  diagrams,  by  design,  contain  no  control  or 
procedural  information,  i.e.,  they  identify  processes  but  not  how  processing 
is  performed  or  controlled.  The  flow  charts  provide  some  of  this  detail. 

The  timeline  associated  with  the  flow  charts  establishes  several  time 
epochs  within  which  the  various  tasks  should  be  performed.  This  timeline 
is  based  on  the  SLBM  Quick  Look  scenario  and  provides  a  time-available  base 
line.  If  the  time  required  to  perform  the  necessary  tasks  exceeds  the  time 
available,  there  can  still  be  a  throughput  problem  (or  bottleneck)  even  though 
there  is  no  congestion  in  the  form  of  queues  of  work. 

To  gather  evidence  of  such  problems,  the  tasks  required  of  each  operator 
in  eacn  time  epoch  were  tabulated.  The  results  are  provided  in  Tables  3-1 
through  3-5. 

It  is  clear  from  these  tables  that  the  first  time  epoch,  associated  with 
processing  event  data,  requires  a  substantial  number  of  tasks,  particularly  of 
the  EVO.  During  this  phase  most  of  the  communications  links  are  established 
and  preliminary  data  are  digested  and  briefed.  Later  epochs  also  involve 
substantial  numbers  of  tasks,  but  they  consist  primarily  of  briefing  infor¬ 
mation  or  entering  data  into  the  computer  systems. 

All  tasks  listed  in  the  tables  can  be  classified  as: 

1.  Configuring  a  resource. 

2.  Briefing  or  otherwise  passing  information  by  voice  to  another 
user  or  operator. 

3.  Enter  data  into  automatic  data  processing  equipment. 

It  is  perhaps  significant  that  there  are  no  judgement  tasks  (i.e.,  tasks  with 
open-ended  completion  times)  per  se  performed  by  the  operators  in  the  system 
under  consideration  in  this  scenario.  The  task  closest  to  a  problem-solving 
exercise  appears  to  be  plotting  coordinates,  and  that  obviously  is  a  rather 
routine  activity.  It  appears,  therefore,  that  good  performance  in  this  system 
depends  on  the  ability  to  pass  along  information  in  a  timely  fashion.  The 
remaining  analysis  will,  therefore,  address  the  question  of  whether  or  not  the 
tasks  as  described  can  reasonably  be  performed  in  the  time  available.  Since 
the  most  demanding  time  requirements  are  placed  on  the  EVO  during  the  event 
processing  stage,  this  stage  will  be  analyzed  in  detail. 


TABLE 

3-1.  TASKS 

PERFORMED  EPOCH  I  -  PROCESSING  EVENT  REPORTS 

OPERATOR 

TASK 

# 

TASK  NAME 

mwtl 

2.6 

Request  Confirmation  of  Event  Message 

2.30 

Enter  Valid  on  NCS,  MEBU 

mwt2 

2.7 

Enter  Data  into  MEBU 

2.30 

Enter  Valid  into  NCS,  MEBU 

EVO 

2.8 

Initialize  Beige  Loop 

2.9 

Obtain  Data 

2.12 

Plot  Coordinates 

2.18 

Receive  System  Reports 

2.20 

or 

2.26 

Brief  Info  to  CD 

CD 

2.3 

Receive  Briefing 

2.5 

Receive  Briefing  from  Other  Centers 

2.13 

Ask  ACD  to  Initiate  Call  to  Second  Assessor 

2.21 

Receive  MWC  Briefing 

2.27 

Give  MWC  Direction  to  Enter  Valid 

AD 

2.32 

Monitor  NCS,  Panels 

A  CD 

2.14 

Initiate  Request  for  MDC 

2.23 

Call  Secondary  Assesor 

2.24 

Call  NMCC 

2.33 

Receive  Authorization/Maintain  MDC 

TABLE  3-2.  TASKS  PERFORMED  EPOCH  II  -  DEVELOPING  CSD 


OPERATOR 

TASK  if 

TASK  NAME 

MWT 

3.2 

Receive  Radar  Site  Report 

3.4 

Confirm  Report  via  Phone,  Report  "Valid" 

EVO 

3.5 

Recommend  System  Report,  Brief  CD 

CD 

3.6 

Receive  Briefings;  Tell  ACD  to  Call  C1NC 

3.11 

Monitor  Beige  Loop  and  NCS 

3. 12 

Maintain  Voice  Contact  with  CINC 

ACD 

3.7 

Call  CINC 

3.10 

Stay  on  line  to  MDC;  Monitor  Beige  Loop 

TABLE  3-3.  TASKS  PERFORMED  EPOCH  III  -  OBTAINING  CINC  ASSESSMENT 


OPERATOR 

TASK  # 

TnSK  NAME 

EVO 

3.16 

Report  Point  of  Impact  over  Beige 

Loop 

CD 

3.17 

Request  CINC  Assessment 

3.19 

Receive  CINC  Assessment 

3.21 

Tell  EVO  to  Enter  CINC  Assessment 

into  NCS 

TABLE  3-4.  TASKS  PERFORMED  EPOCH  IV  -  OBTAINING  CINC  ASSESSMENTS 
AND  UPDATING  CSD 


OPERATOR 

TASK  # 

TASK  NAME 

MWTi 

3.23 

3.26 

Enter  CINC  Assessment 

Maintain  Voice  Contact  with  Radar  Site 

MWT2 

3.24 

Enter  CINC  Assessment 

EVO 

3.28 

Report  that  Assessment  and  Radar  Site 
Reports  are  in  NCS 

ACD 

3.22 

Brief  MDC  on  CINC  Assessment 

TABLE  3-5. 

TASKS  PERFORMED 

EPOCH  V  -  SENDING  TW/AA  MESSAGES 

OPERATOR 

TASK  # 

TASK  NAME 

EVO 

4.4 

Brief  Info  from  NCS  on  Beige  Loop 

CD 

4.2 

Receiver  Radar  Site  Message 

4.5 

Receive  Briefing  from  MWC 

4.6 

Brief  CINC 

4.11 

Request  CINC  Assessment 

4.13 

Receive  CINC  Assessment 

ACD 

4.2 

Receive  Radar  Site  Message 

4.8 

Maintain  MDC 

4.9 

Ask  if  MDC  Continue? 

4.10 

Brief  MDC  on  AA  Message 

47 


$ 

ft 


3.4.3  Analysis  of  Time-Critical  Activities 


As  shown  In  Table  3-1  the  EVO  must  initiate  the  Beige  Loop,  obtain  report 
data,  plot  coordinates,  receive  reports,  and  brief  the  CD,  all  within  a  very 
short  time.  Each  task  is  now  considered  in  detail. 


Initiate  Beige  Loop 

According  to  Task  Description  Worksheet  (TDW)  #13  (Appendix  C) ,  this  task 
requires  three  steps: 


1. 

Pick 

up 

receiver. 

2. 

Wait 

for 

CD  to  acknowledge. 

3. 

Declare 

"Missile  Initiating. 

At  this  point  information  is  passed  to  parties  on  the  loop.  Estimates 
of  the  missile  warning  personnel  suggest  that  this  task  takes  5-15  seconds. 
If  we  assume  that  this  is  normally  distributed,  we  can  define  tg^  as  the  Beige 
Loop  initiating  time  and 


tBL  “  N(10,  6.25) 


i.e.,  CBL  is  a  normally  distributed  random  variable  with  variance  6.2.,.  The 
variance  was  estimated  by  assuming  the  range  of  the  data  is  four  standard 
deviations.  These  data  seem  quite  reasonable  when  compared  against  the  sub¬ 
tasks  involved. 


Obtain  Data  and  Plot  Coordinates 

"Obtain  Data"  and  "Plot  Coordinates"  are  treated  as  one  task  in  the 
training  documents.  TDW  #39  suggests  four  steps: 

1.  Extract  latitude  and  longitude  from  a  sensor  message. 

2.  Select  proper  map. 

3.  Plot  coordinates. 

4.  Convert  plotted  point  to  geographical  location. 

No  estimate  of  completion  times  was  obtained  from  the  crews,  so  one  will  be 
synthesized.  An  estimate  of  the  range  will  be  made  and  then  converted  to 
mean  and  variance.  These  data  are  summarized  in  Table  3-6.  The  total  task 
completion  time  is,  therefore, 
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tpc  “  C1  +  t2  +  c3  +  t4 


E(tpc)  “  I  E(t^) 
i  -1 


V(tpc) 


I  V(tl) 
i*l 


20  sec. 


5.75  sec. 


where  E(*)  refers  to  the  expected  value  (or  mean)  and  V(‘)  Is  the  variance 
Therefore,  the  estimate  for  plot  coordinates  is 

tpc  -  N(20,  5.75)  . 

TABLE  3-6.  ESTIMATED  COMPLETION  TIMES  FOR  PLOT  COORDINATES 


Receive  System  Report 

According  to  TDW  it 43,  this  task  requires  that  the  EVO  receive  the  data 
verbally  and  in  hard-copy  form.  These  data  consist  of  one  of  four  classifi¬ 
cations:  false,  under  investigation,  valid,  all  clear.  It  is  assumed  that 
this  task  is  accomplished  in  0.5  to  1.5  seconds,  or, 


tRSR  a  N(1.0,  .0625), 


XX 
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Brief 


The  final  task  is  briefing  the  command  post, 
report,  time  of  report,  type  of  report,  location, 
we  have  no  data  concerning  task  completion  times, 

tB  -  N(8,  4). 


The  EVO  must  pass  the  sensor 
and  the  system  report.  Again 
and  we  assume 


Estimate  of  Total  Time  Required 

The  cumulative  completion  time  for  the  EVO  in  this  phase  of  the  problem 
is,  therefore, 


T  =  tBL  +  tPC  +  tRSR  +  tB 


E(T)  =  47 
V(T)  *  16 


T  «  N(47,  16) 


If  this  estimate  is  accurate,  the  95  percent  confidence  interval  on  time 
required  is  approximately 

39  <  T  <  55  . 


We  conclude  that  the  probability  of  one  individual's  completing  these  tasks 
within  the  time  available  for  Time  Epoch  I  is  essentially  zero,  and  that  the 
EVO's  activities  constitute  a  critical  path  for  Time  Epoch  I. 

For  purposes  of  illustration  it  is  useful  to  consider  one  additional  set 
of  tasks  in  Time  Epoch  I,  namely  those  performed  by  the  CD  when  obtaining  CINC 
assessment  (Table  3-3).  Again,  a  time  budget  is  allocated  in  the  scenario  to 
request  the  assessment,  receive  the  assessment,  and  tell  the  EVO  to  enter  the 
assessment  into  the  NCS.  If  only  a  few  seconds  are  required  for  each  step, 
the  available  time  is  sufficient.  This,  however,  assumes  that  the  CINC  assess¬ 
ment  is  determined  at  the  time  the  request  is  made.  In  other  words,  CINC  must 
anticipate  the  requirement  and  have  it  available  at  the  required  time. 

Similar  examples  can  be  found  at  several  places  throughout  the  system. 
These  all  show  the  importance  of  well  trained  and  integrated  crews.  A  new 
crew  member  or  substitute  might  not  be  able  to  anticipate  the  needs  of  other 
crew  members,  and  total  performance  would  degrade. 
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3.4.4  Conclusions 


The  conclusions  are  of  two  classes,  specific  to  the  MWC/CP  application 
exercise  and  methodological. 

Even  though  a  complete  analysis  of  each  task  was  not  performed,  it  was 
demonstrated  that  sufficient  time  is  not  available  for  completion  of  all  tasks 
as  required  by  the  formal  system  description.  This  may  account  for  many  of 
the  reports  of  substantial  differences  in  crew  operating  styles  and  substan¬ 
tial  informal  communication  and  informal  organization. 

The  findings  also  emphasize  the  need  for  good  training.  Crew  members 
must  be  aware  of  the  requirements  and  expectations  placed  on  other  members  of 
the  team.  This  enables  compensating  behavior  on  the  part  of  less  loaded  crew 
members  to  aid  more  highly  loaded  members  even  though  such  aiding  may  not  be 
called  for  in  the  formal  task  descriptions. 

In  terms  of  methodology,  several  conclusions  are  important.  First,  the 
structural  and  descriptive  data  provided  by  IAT  are  quite  complete  and  support 
a  variety  of  analyses.  By  carefully  analyzing  the  data  flows  and  flow  charts, 
it  was  possible  to  identify  system  performance  characteristics  and  potential 
problems.  This  analysis  can  be  qualitative  or  quantitative.  Quantitative 
analysis  is  somewhat  more  speculative  and  requires  more  detail  about  processes 
such  as  that  provided  by  the  task  description  worksheets. 

The  NORAD  example  reinforces  the  need  to  have  a  number  of  analysis  tech¬ 
niques  rather  than  just  one.  An  early  IAT  assumption  was  that  queues  would 
be  sufficient  for  quantifying  congestion,  but  that  is  not  true  as  demonstrated 
by  this  example.  In  this  system  the  process  is  more  like  a  project  management 
problem  in  that  several  activities  are  performed,  some  in  parallel,  some  in 
sequence,  in  order  to  complete  this  overall  task.  Congestion  occurs  because 
of  the  precedence  requirements  placed  on  activities.  If  overall  completion 
times  are  not  satisfactory,  the  activities  on  the  critical  path  must  be  exam¬ 
ined.  Improved  time-lines  might  result  from  reallocation  of  resources  to  the 
activity,  a  redefinition  of  the  procedures,  or  better  work  aids.  But  it  is 
the  critical  path  that  deserves  this  attention. 

Queuing  theory,  on  the  other  hand,  would  be  appropriate  when  congestion 
is  due  to  operators  performing  relatively  homogeneous  tasks  in  a  repetitive 
fashion.  Further,  queuing  requires  that  work  or  tasks  are  somehow  buffered 
In  the  system. 

The  general  lesson  to  be  learned  is  that  one  of  the  primary  benefits  of 
lAT's  structured  approach  is  a  good,  complete  descriptive  database.  Given 
such  data,  an  analyst  can  formulate  many  ways  to  answer  questions,  and  it 
would  be  counterproductive  and  inefficient  to  constrain  the  set  of  tools  at 
this  (or,  possibly,  any)  stage.  It  is  also,  perhaps,  naive  to  assume  that 
the  process  can  be  performed  without  a  skilled  analyst  at  our  current  state 
of  knowledge.  However,  future  systematic  application  of  IAT,  especially  in  a 
compute! — assisted  form,  should  result  in  comprehensive  databases  that  will 
support  the  necessary  methodology  to  make  the  skilled  analyst  less  necessary 
in  the  future. 


51 


Finally,  experience  to  date  suggests  that  quantitative  analysis  is  some¬ 
what  speculative  because  of  imprecise  and  missing  data.  This  suggests  that 
valid  quantitative  analysis  is  probably  restricted  to  (1)  comparisons  of 
alternative  system  implementations  in  which  some  base  data  can  be  used,  or 
(2)  sensitivity  analyses.  Both  types  of  analysis  are  extremely  useful  and 
helpful  in  system  design,  so  such  applications  are  not  severe  restrictions 
on  the  use  of  IAT  at  present.  However,  it  is  anticipated  that  as  IAT  matures 
and  a  full  set  of  frame  types  and  their  associated  templates  are  developed, 
the  problem  of  data  voids  will  diminish  through  more  complete  data  collection 
and  the  use  of  acceptable  default  values. 
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SECTION  4 


AIR  DEFENSE  APPLICATION* 


4.1  INTRODUCTION 

In  this  section,  a  complete  Petri  net  representation  of  a  more  complex 
C3  system  involved  in  an  air  defense  mission  is  presented.  According  to  the 
IAT  methodology  described  in  Volume  I,  a  hierarchical  Petri  net  representa¬ 
tion  with  five  levels  of  detail  was  developed.  Each  of  the  first  four  levels 
represents  the  entire  air  defense  system.  Level  V  represents  those  areas  of 
the  system  which  require  more  detail  than  could  be  accommodated  in  Level  IV. 

Levels  I  and  II  consist  of  a  single  diagram  each  and  provide  highly 
aggregated  representations  of  the  air  defense  system.  Due  to  the  increased 
detail  in  Levels  III  -  V,  we  make  no  attempt  to  represent  these  levels  on  a 
single  page.  Thus,  Level  III  consists  of  Diagrams  Three  and  Four;  Level  IV 
consists  of  Diagrams  Five  through  Fourteen;  and  Level  V  consists  of  Diagrams 
Fifteen  through  Twenty.  Diagrams  Twenty-one  through  Twenty-three  are  supple¬ 
ments  that  present  additional  detail  that  is  appropriate  to  several  different 
places  in  Level  V.  We  partitioned  Levels  III  -  V  into  subsets  of  higher 
levels  along  the  following  lines:  major  air  defense  functions  (i.e.,  detec¬ 
tion,  tracking,  identification,  weapons  allocation,  and  engagement),  and  class 
of  target  (i.e.,  friendly  or  hostile).  For  ease  of  reference  each  diagram 
has  a  number  indicating  the  level  of  detail  it  represents,  as  well  as  lateral 
pointers  to  indicate  connections  to  diagrams  on  the  same  level. 

Level  I  stresses  the  major  concerns  of  the  air  defense  mission,  that  is 
leakage  of  hostile  aircraft  and  fratricide  of  friendly  aircraft,  at  a  very 
aggregated  level.  Levels  II  -  V  answer  the  "why"  questions  associated  with 
leakage  and  fratricide,  i.e.,  "why  did  this  hostile  leak?"  or  "why  was  this 
friendly  aircraft  prosecuted?"  Levels  II  and  III  approach  these  issues  in  a 
fairly  aggregate  fashion;  e.g.,  the  hostile  escaped  because  it  was  not  detec¬ 
ted,  the  friendly  was  prosecuted  because  it  was  incorrectly  identified,  and 
so  on.  Levels  IV  and  V  introduce  a  greater  level  of  complexity  to  these  ques¬ 
tions  and  point  specifically  to  system  capabilities,  such  as  load  capacity 
and  resource  availability,  as  well  as  to  the  effect  of  enemy  attempts  to  dis¬ 
rupt  the  command  and  control  process  through  jamming  and  direct  strikes  on 
resources . 


*This  application  was  supported  by  BDM  Corporation  subcontract  S562-0300512 , 
under  Defense  Communications  Agency  Contract  DCAI00-85-C-0063. 
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In  developing  the  Petri  net  representations  which  are  contained  in  this  ] 

section,  we  tried  to  strike  a  balance  between  a  rigid  hierarchy  and  one  which  i 

provides  enough  flexibility  to  obtain  useful  measures.  Likewise,  we  simpli-  J 

fled  our  representations  wherever  possible,  while  trying  to  maintain  the 

flexibility  for  extensions.  Thus,  at  Level  IV,  we  discuss  only  bombers  and  • 

fighters;  however,  the  Petri  net  representation  is  general  enough  to  be  appli-  ] 

cable  to  cruise  missiles  and  helicopters.  > 

\ 

The  remainder  of  this  section  consists  of  the  diagrams  which  make  up  the  j 

Petri  net  representation  for  Levels  I  -  V,  plus  the  supplementary  diagrams  of 
the  air  defense  mission.  Each  diagram  is  accompanied  by  a  description  of  the  ' 

flow  of  tokens  through  that  section  of  the  Petri  net.  The  minimal  independent 
set  of  measures  associated  with  these  diagrams  is  discussed  in  Section  5. 

4.2  LEVEL  I 

Level  I  stresses  the  two  major  concerns  of  the  air  defense  system:  leak¬ 
age  and  fratricide.  At  this  highly  aggregated  level,  we  focus  on  the  destruc¬ 
tion  of  hostile  aircraft  in  the  Air  Defense  Region  (ADR)  versus  the  leakage 
of  hostile  aircraft  out  of  the  ADR,  and  the  safe  passage  of  friendly  aircraft 
through  the  ADR  versus  the  fratricide  or  destruction  of  friendly  aircraft. 

Here  we  are  concerned  solely  with  the  aggregate  rates,  probabilities,  and 
delays  associated  with  leakage  and  fratricide.  At  lower  levels,  we  break 
these  down  further  (e.g.,  leakage  prior  to  mission  completion,  leakage  of  j 

damaged  hostile  aircraft,  etc.).  j 

j 

The  air  defense  mission  is  concerned  with  destroying  enemy  aerospace 
forces  in  a  given  region,  and  allowing  friendly  aerospace  forces  to  operate 
safely  in  that  region.  Clearly  then,  an  effective  air  defense  system  is  one 
which  reduces  leakage  and  fratricide. 

4.2.1  Diagram  One 

Diagram  One  represents  the  entire  air  defense  system  at  a  highly  aggre¬ 
gated  level.  In  Diagram  One,  hostile  aircraft  entering  the  ADR  are  either 
destroyed  by  the  air  defense  system  or  they  escape  from  the  regions.  Simi¬ 
larly,  friendly  aircraft  entering  the  region  are  either  destroyed  by  the  air 
defense  system  or  they  exit  from  the  region.  (Note  that  friendly  aircraft 
does  not  include  air  defense  weapons  such  as  fighter-interceptors  or  surveil¬ 
lance  assets  such  as  AWACS.) 

The  difference  between  the  two  paths  through  the  ADR  is  that  the  numbers 
associated  with  destruction  and  escape/exit  should  be  radically  different  for 
hostile  and  friendly  aircraft.  Specifically,  an  effective  air  defense  system 
will  show  a  larger  proportion  of  the  tokens  representing  hostile  aircraft 
firing  the  "air  defense  system  destroys  hostile  aircraft"  transition  than 
the  "hostile  aircraft  escapes  from  ADR"  transition,  and  a  larger  proportion 
of  the  tokens  representing  friendly  aircraft  firing  the  "friendly  aircraft 
exits  from  the  ADR"  transition  than  the  "air  defense  system  destroys  friendly  ' 
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aircraft."  In  other  words,  an  effective  air  defense  system  will  have  high 
hostile  destruction  and  safe  friendly  passage  rates  (or,  low  leakage  and 
fratricide  rates). 


4.3  LEVEL  II 

Level  II  introduces  two  functions  of  the  air  defense  systems,  detection 
and  weapons  allocation,  as  well  as  two  groups  of  assets  available  to  the  air 
defense  system,  namely  surveillance  assets  and  air  defense  weapons.  At  Level 
II  we  are  still  focusing  primarily  on  leakage  and  fratricide.  At  this  level  , 
leakage  occurs  at  three  points:  the  hostile  target  escapes  before  being 
detected,  after  detection  and  prior  to  prosecution,  or  in  the  course  of  being 
prosecuted.  Fratricide  occurs  when  a  friendly  aircraft  is  "successfully" 
prosecuted  by  the  air  defense  system;  i.e.,  the  friendly  gets  in  the  "target 
stream"  and  does  not  exit  from  it  before  detection,  before  weapons  allocation, 
and/or  does  not  escape  prosecution. 


4.3.1  Diagram  Two 

Diagram  Two  is  a  refinement  of  Diagram  One  and  shows  in  greater  detail 
how  the  air  defense  system  reacts  to  aircraft  in  the  ADR.  Targets  (hostile 
and  friendly)  entering  the  region  may  be  detected;  if  detected  and  identified, 
they  may  be  assigned  to  weapons  and  prosecuted;  and  if  prosecuted,  they  may  be 
destroyed.  Likewise,  targets  which  have  entered  the  ADR  may  leave  the  region 
without  being  detected;  if  detected,  they  may  leave  without  being  prosecuted; 
and,  if  subject  to  prosecution,  they  may  still  escape  the  region. 

Diagram  Two  introduces  two  classes  of  assets  available  to  the  air  defense 
system:  surveillance  assets  and  air  defense  weapons.  The  dotted  lines  con¬ 
necting  the  population  of  surveillance  assets  to  the  "Detect  Target"  transi¬ 
tions  indicate  that  surveillance  assets  (e.g. ,  radars)  do  not  operate  on  a 
one-to-one  basis  with  targets  that  are  detected;  that  is,  these  assets  do  not 
become  unavailable  as  targets  are  detected.  Some  surveillance  assets,  how¬ 
ever,  must  be  available  in  order  for  detection  to  take  place  at  all.  Note 
that  surveillance  assets  do  become  unavailable  as  they  are  destroyed  by  enemy 
action.  In  contrast  to  surveillance  assets,  air  defense  weapons  do  prosecute 
targets  one  at  a  time.  Thus,  while  prosecuting  an  individual  target,  a  weapon 
is  not  available  to  prosecute  other  targets  (ignoring  interrupts).  Like  sur¬ 
veillance  assets,  air  defense  weapons  can  be  destroyed  by  enemy  action  apart 
from  engagements. 

The  representation  of  a  target  engagement  in  Diagram  Two  is  deliberately 
simplified.  At  this  level,  an  engagement  may  result  in  two  possible  outcomes: 
the  target  may  escape,  in  which  case  the  air  defense  weapon  is  assumed  de¬ 
stroyed;  or,  the  target  is  destroyed,  in  which  case  the  air  defense  weapon  is 
shown  as  becoming  available  (after  some  period  of  time  for  refueling,  etc.). 
Diagrams  Nine  through  Fourteen  at  Level  IV  and  Diagram  Twenty  at  Level  V  give 
more  detailed  presentations  of  the  possible  outcomes  of  an  engagement. 
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Figure  4-2.  Level  II  -  Diagram  Two 
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4.4  LEVEL  III 


Level  III  introduces  the  tracking  and  identification  functions  of  the  air 
defense  system.  Given  the  increased  detail,  Level  III  and  subsequent  levels 
cannot  be  adequately  presented  on  a  single  page.  For  Level  III,  we  present 
the  air  defense  system  in  two  diagrams.  Diagram  Three  presents  the  activi¬ 
ties  of  the  air  defense  system  relative  to  hostile  aircraft.  Diagram  Four 
presents  the  parallel  development  for  friendly  aircraft.  Diagrams  Three  and 
Four  are  identical,  except  that  the  tokens  in  the  network  represent  different 
groups  of  targets.  When  this  situation  occurs  at  subsequent  levels,  we  will 
present  only  one  diagram  and  discuss  the  parallel  situations  in  the  text.  For 
continuity  we  maintain  the  distinction  between  hostile  and  friendly  aircraft 
at  Level  III. 


4.4.1  Diagram  Three 


Diagram  Three  refines  the  activities  of  the  air  defense  system  relative 
to  hostile  aircraft  as  presented  in  Diagram  Two.  In  Diagram  Three,  hostile 
aircraft  entering  the  ADR  may  be  detected  (if  surveillance  assets  exist).  If 
the  hostile  aircraft  are  detected,  the  air  defense  system  will  attempt  both 
to  identify  and  i.u  tiack  Lhe  aircraft.  The  activities  of  tracking  and  identi¬ 
fication  are  also  dependent  on  the  existence  (and  nature)  of  the  surveillance 
assets.  If  the  hostile  aircraft  are  both  identified  and  tracked,  weapons  may 
be  allocated  to  prosecute  the  aircraft.  If  weapons  are  allocated,  they  become 
unavailable  for  the  duration  of  the  engagement.  In  this  simplified  represen¬ 
tation,  either  the  aircraft  escapes  or  it  is  destroyed;  if  it  is  destroyed, 
the  air  defense  weapon  becomes  available  to  prosecute  other  aircraft.  For 
greater  detail  of  the  engagement  of  hostile  aircraft,  see  Diagrams  Nine  through 
Thirteen  at  Level  IV  and  Diagram  Twenty  at  Level  V. 


4.4.2  Diagram  Four 


Diagram  Four  refines  the  activities  of  the  air  defense  system  relative 
to  friendly  aircraft  as  presented  in  Diagram  Two.  Diagram  Four  is  identical 
to  Diagram  Three,  except  that  the  tokens  represent  different  populations  of 
aircraft.  In  Diagram  Four,  friendly  aircraft  entering  the  ADR  may  be  detected 
(if  surveillance  assets  are  available).  If  the  friendly  aircraft  are  detected, 
the  air  defense  system  will  attempt  both  to  Identify  and  to  track  the  air¬ 
craft.  If  the  friendly  aircraft  are  both  identified  and  tracked,  weapons  may 
be  allocated  (if  incorrectly  identified  as  hostile  or  unknown)  to  prosecute 
the  aircraft.  If  weapons  are  allocated,  they  become  unavailable  for  the  dur¬ 
ation  of  the  engagement.  As  in  Diagram  Three,  this  simplified  representation 
shows  that  either  the  friendly  aircraft  escapes  and  exits  the  ADR  or  it  is 
destroyed;  if  it  is  destroyed,  the  air  defense  weapon  becomes  available  to 
prosecute  other  aircraft.  For  greater  detail  of  the  engagement  of  hostile 
aircraft,  see  Diagrams  Nine,  Twelve,  and  Fourteen  at  Level  IV  and  Diagram 
Twenty  at  Level  V. 


HOSTILE 

HOSTILE 

UNDETECTED 

AIRCRAFT 

AIRCRAFT 

HOSTILE 

ESCAPE 

ESCAPE 

AIRCRAFT 

WITHOUT  ID 

WITHOUT 

ESCAPE 

4  TRACK 

PROSECUTION 

|  AIR  DEFENSE  ■ 

WEAPONS 

I  DESTROYED  ! 

I _ J 

LEVEL  III  -  DIAGRAM  3  «-J«H 


Figure  4-3.  Level  III  -  Diagram  Three 
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Note  that  the  populations  of  surveillance  assets  and  air  defense  weapons 
In  Diagrams  Three  and  Four  are  the  same  populations.  Thus,  If  an  air  defense 
weapon  Is  allocated  to  a  friendly  aircraft,  then  It  Is  not  available  to  prose¬ 
cute  a  hostile  aircraft  (and  vice  versa). 


4.5  LEVEL  IV 

Level  IV  is  presented  in  Diagrams  Five  through  Fourteen.  The  flow  of 
tokens  through  the  diagrams  at  Level  IV  is  shown  in  Fig.  4-5. 
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Figure  4-5.  Diagrams  in  Level  IV 


Level  IV  introduces  several  new  concepts.  First,  a  distinction  is  drawn 
between  post-mission  and  pre-mission  hostile  aircraft.  Post-mission  hostiles 
are  those  hostiles  which  have  completed  their  missions  and  are  on  their  way 
out  of  the  ADR.  Pre-mission  hostiles  are  those  hostiles  which  are  en  route  to 
their  missions.  A  successful  air  defense  system  will  decrease  the  number  of 
post-mission  hostiles  by  detecting,  tracking,  identifying  and  prosecuting  hos¬ 
tile  aircraft  before  they  complete  their  missions.  Obviously,  in  a  heavy  load 
situation,  some  trade-offs  will  occur  based  on  what  the  perceived  missions  of 
incoming  hostiles  are,  i.e.,  the  air  defense  system  will  want  to  protect  its 
high  value  targets. 

Second,  Level  IV  introduces  spoofing,  or  the  generation  of  false  targets. 
Spoofing  is  important  because  it  places  a  greater  load  on  the  air  defense  sys¬ 
tem,  taking  up  surveillance,  communications,  and  data  processing  assets  as 
well  as  critical  air  defense  weapons,  and  disrupts  the  command  and  control 
process . 
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Communications  and  data  processing  assets  are  also  introduced  at  Level  IV. 
Communications  assets  are  represented  as  circuits  which  are  taken  up  as  mes¬ 
sages  are  sent  and  as  enemy  jamming  is  introduced.  Circuits  are  freed  up  as 
messages  are  completed,  jamming  is  overcome,  etc.  For  more  detail  of  this 
process,  see  supplementary  Diagram  Twenty-one.  Data  processing  is  represented 
in  terras  of  capacity,  that  is,  as  more  data  processing  is  required,  the  capa¬ 
city  is  reduced.  The  presence  of  limited  communications  assets  and  data  proc¬ 
essing  capacity  introduces  the  notion  that  the  air  defense  system  can  only 
handle  a  limited  load,  which,  when  exceeded,  results  in  the  degradation  of  the 
functioning  of  the  air  defense  system.  (Note,  we  explicitly  represent  data 
processing  capacity  in  Diagrams  Six  and  Seven.  For  simplicity,  we  omit  expli¬ 
cit  reference  to  data  processing  in  Diagrams  Eight  through  Fourteen). 

At  Level  IV,  the  identification  process  is  broken  down  into  two  steps: 
identification  by  "nationality"  friend  or  foe  (IFF),  and  identification  by 
type  (as  bomber  or  fighter).  With  the  differentiation  between  bombers  and 
fighters,  we  introduce  the  notion  of  selective  targeting  in  the  allocation 
process.  This  provides  the  flexibility  to  model  a  variety  of  strategies 
regarding  targeting.  Finally,  Level  IV  provides  a  detailed  representation  of 
the  engagement  process  for  a  wide  range  of  targets  (post-mission  hostiles, 
pre-mission  hostiles,  false  targets,  and  friendlies). 


4.5.1  Diagram  Five 

Diagram  Five  presents  the  activities  of  the  air  defense  system  relative 
to  the  detection  of  hostile  aircraft.  It  shows  that  hostiles  entering  the  ADR 
may  be  detected  (if  surveillance  assets  are  available).  If  detected  before 
their  missions  are  complete,  they  become  pre-mission  hostiles;  If  detected 
after  completing  their  missions,  they  become  post-m1 «sion  hostiles. 

Diagram  Five  presents  three  new  concepts  in  the  air  defense  system: 
spoofing,  communications,  and  data  processing.  Spoofing  refers  to  the  activ¬ 
ity  by  which  hostile  forces  Introduce  false  targets  into  the  air  defense  sys¬ 
tem.  Diagram  Fifteen  at  Level  V  presents  spoofing  in  greater  detail.  Commu¬ 
nications  assets,  represented  here  as  circuits,  are  a  limited  resource  needed 
for  each  transition  through  the  system.  We  show  communications  assets  being 
freed  up  as  messages  are  completed,  jamming  is  overcome,  etc.  Supplementary 
Diagram  Twenty-one  shows  this  activity  in  greater  detail. 

Data  processing  is  also  a  limited  resource  in  terms  of  capacity.  This 
limited  capacity  may  result  in  targets  being  lost  from  the  system  even  though 
surveillance  and  communications  assets  are  available.  If  surveillance  and 
communications  assets  are  available,  and  if  database  capacity  is  available, 
both  hostile  aircraft  and  false  targets  will  be  entered  into  the  database 
until  the  capacity  is  exceeded.  Notice  that  data  processing  capacity  becomes 
available  as  targets  leave  the  ADR  or  leave  the  system  (because  of  lost  or 
dropped  tracks),  or  are  destroyed. 
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4.5.2  Di agrarn  Six 

Diagram  Six  shows  the  activities  of  the  air  defense  system  detecting 
friendly  aircraft.  In  Diagram  Six,  friendly  aircraft  entering  the  region  may 
be  detected  if  surveillance  assets  are  available,  or  they  may  exit  without 
detection;  if  detected  and  data  processing  capacity  is  available,  they  may  be 
entered  into  the  database,  or  they  may  exit  without  being  entered  into  the 
database.  As  in  Diagram  Five,  communications  assets  must  be  available  in 
order  to  note  a  detection  and  to  enter  it  into  the  database. 


4.5.3  Diagram  Seven 

Diagram  Seven  presents  more  details  of  the  ident i f icat ion  process.  In 
this  representation,  a  target  is  first  identified  by  nationality  (Friend  or 
Foe).  Diagram  Seven  represents  four  situat Lows :  the  identification  of  post¬ 
mission  hostile  aircraft,  the  identif ication  of  pre-mission  hostile  aircraft, 
the  identification  of  false  targets,  and  the  identification  of  friendly  air¬ 
craft.  Thus,  there  are  four  sets  of  tokens  which  can  flow  through  the  Petri 
net  representation  in  Diagram  Seven. 

Given  that  a  target  is  identified,  it  may  be  identified  as  either  hos¬ 
tile,  false,  or  friendly.  If  a  target  is  not  identified,  it  is  classified  as 
unknown.  The  likelihood  of  these  particular  identifications  will  depend  on 
the  type  of  target  being  identified  as  well  as  the  surveillance  assets  avail¬ 
able  for  identification. 

A  target  may  "Leave  the  System"  before  it  is  identified,  either  by  physi¬ 
cally  leaving  the  region  or  because  the  system  loses  the  target  track.  Also, 
if  a  target  is  identified  as  friendly  or  false,  it  eventually  leaves  the  sys¬ 
tem,  unless  it  is  re-identified. 

As  before,  the  dotted  line  means  that  the  electronic  assets  are  necessary 
for  those  identifications  to  occur,  but  they  do  not  become  unavailable  as 
identifications  occur. 

For  a  more  detailed  presentation  of  identification  by  nationality,  see 
Diagram  Seventeen  at  Level  V. 

4.5.4  Diagram  Eight 

Diagram  Eight  is  similar  to  Diagram  Seven  and  represents  the  common  ways 
a  target  identified  as  unknown  or  hostile  can  be  further  identified  according 
to  type  as  a  bomber  or  a  fighter. 

The  attempt  to  identify  the  target  by  typ°  may  conclude  that  the  target 
is  a  false  target  or  that  it  is  in  fact  friendly;  otherwise  it  will  be  iden¬ 
tified  as  an  (unknown/hostile)  bomber  or  (unknown/hostile)  fighter.  (These 
classifications  are  illustrative;  others,  e.g.  ,  cruise  missiles,  may  be  intro¬ 
duced  as  needed).  This  representation  assumes  that  a  target  that  cannot  be 
identified  by  type  will  be  classified  as  a  bomber. 
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Figure  4-7.  Level  IV  -  Diagram  Six 
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Figure  4-9.  Level  IV  -  Diagram  Eight 


Diagram  Eight  represents  eight  situations  of  identifying  aircraft  by 
type.  The  targets  being  identified  are:  post-mission  hostile  aircraft  iden¬ 
tified  as  unknown,  pre-mission  hostile  aircraft  identified  as  unknown,  false 
targets  identified  as  unknown,  friendly  aircraft  identified  as  unknown,  post¬ 
mission  hostile  aircraft  identified  as  hostile,  pre-mission  hostile  aircraft 
identified  as  hostile,  false  targets  identified  as  hostile,  and  friendly  air¬ 
craft  identified  as  hostile. 

As  before,  the  dotted  line  means  that  the  electronic  assets  are  necessary 
for  those  identifications  to  occur,  but  they  do  not  become  unavailable  as 
identifications  occur. 


4.5.5  Diagram  Nine 

Diagram  Nine  presents  the  weapons  allocation  process.  If  both  bomber 
targets  and  fighter  targets  are  available,  then  the  air  defense  system  must 
have  a  policy  for  allocating  its  assets  between  these  two  groups. 

All  targets  classified  as  bombers  flow  through  the  upper  path  on  the  dia¬ 
gram.  There  are  eight  groups:  post-mission  hostile  aircraft  identified  as 
unknown  bombers,  pre-mission  hostile  aircraft  identified  as  unknown  bombers, 
false  targets  identified  as  unknown  bombers,  friendly  aircraft  identified  as 
unknown  bombers,  post-mission  hostile  aircraft  identified  as  hostile  bombers, 
pre-mission  hostile  aircraft  identified  as  hostile  bombers,  false  targets  iden 
tified  as  hostile  bombers,  and  friendly  aircraft  identified  as  hostile  bombers 

Similarly,  all  targets  classified  as  fighters  flow  through  the  lower  path 
on  the  diagram.  There  are  eight  groups:  post-mission  hostile  aircraft  iden¬ 
tified  as  unknown  fighters,  pre-mission  hostile  aircraft  identified  as  unknown 
fighters,  false  targets  identified  as  unknown  fighters,  friendly  aircraft 
identified  as  unknown  fighters,  post-mission  hostile  aircraft  identified  as 
hostile  fighters,  pre-mission  hostile  aircraft  identified  as  hostile  fighters, 
false  targets  identified  as  hostile  fighters,  and  friendly  aircraft  identified 
as  hostile  fighters. 

Whatever  the  policy  about  allocating  resources  between  fighters  and 
bombers,  allocations  among  pre-  (and  possibly  post-)  mission  hostile  bombers, 
friendly  aircraft  identified  as  hostile  bombers,  and  false  targets  identified 
as  hostile  bombers  will  be  entirely  random,  since  to  the  air  defense  system 
they  represent  one  population,  not  three  (the  same  randomness  applies  for 
allocations  among  all  the  targets  the  system  identifies  as  hostile  fighters). 

Note  that  the  weapon-target  pairings  output  from  Diagram  Nine  go  to  one 
of  five  diagrams:  to  Diagram  Ten  for  post-mission  hostiles  identified  as  hos¬ 
tile  bombers  and  fighters;  to  Diagram  Eleven  for  pre-mission  hostiles  iden¬ 
tified  as  hostile  bombers  and  fighters;  to  Diagram  Twelve  for  all  targets 
classified  as  unknown  bombers  and  fighters;  to  Diagram  Thirteen  for  false 
targets  identified  as  hostile  bombers  and  fighters;  or,  to  Diagram  Fourteen 
for  friendly  aircraft  identified  as  hostile  bombers  and  fighters. 
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4.5.6  Diagram  Ten 


Diagram  Ten  represents  the  air  defense  system's  engagement  of  post¬ 
mission  hostile  aircraft  that  nave  been  identified  as  hostile  by  the  air 
defense  system.  (The  engagement  of  post-mission  hostile  aircraft  which  have 
been  identified  as  unknown  is  shown  in  Diagram  Twelve).  Diagram  Ten  repre¬ 
sents  two  classes  of  post-mission  hostile  aircraft:  bombers  and  fighters. 
These  two  populations,  post-mission  hostile  bombers  and  post-mission  hostile 
fighters,  come  from  three  transitions,  thus  representing  more  than  one  possi¬ 
ble  path  through  the  air  defense  system. 

Diagram  Ten  may  represent:  the  first  (or  subsequent)  engagement  of  a 
post-mission  hostile  aircraft  wnich  was  initially  identified  as  a  hostile 
bomber  or  fighter  (from  Diagram  Nine);  the  engagement  of  a  post-mission  hos¬ 
tile  aircraft  which  escaped  an  engagement  prior  to  completing  its  mission 
(from  Diagram  Eleven);  or,  the  engagement  of  a  post-mission  hostile  aircraft 
which  was  initially  identified  as  an  unknown,  paired  with  an  air  defense  wea¬ 
pon,  and  then  identified  as  hostile  (from  Diagram  Twelve). 

Depending  on  the  strategy  selected,  the  engagement  of  post-mission  hos- 
tiles  may  or  may  not  take  place.  For  instance,  if  the  air  defense  system 
stresses  an  area  defense,  it  will  allocate  weapons  to  aircraft  ingressing  and 
egresslng  equally;  if  it  stresses  point  defense,  then  aircraft  on  the  way  to 
their  target  will  be  engaged  in  preference  to  aircraft  exiting. 


4.5.7  Diagram  Eleven 

Diagram  Eleven  represents  the  air  defense  system's  engagement  of  pre¬ 
mission  hostile  aircraft  that  have  been  identified  as  hostile  bombers  and 
fighters  by  the  air  defense  system.  (The  engagement  of  pre-mission  hostile 
aircraft  which  have  been  identified  as  unknown  is  shown  in  Diagram  Twelve). 
Diagram  Eleven  represents  two  classes  of  pre-mission  hostile  aircraft:  bomb¬ 
ers  and  fighters.  These  two  populations,  pre-mission  hostile  bombers  and  pre¬ 
mission  hostile  fighters,  come  from  two  transitions,  thus  representing  more 
than  one  possible  path  through  the  ADR. 

Diagram  Eleven  may  represent  the  first  (or  subsequent)  engagement  of  a 
pre-mission  hostile  aircraft  which  has  been  identified  as  a  hostile  bomber 
or  fighter  (from  Diagram  Nine);  or,  a  pre-mission  hostile  aircraft  which  was 
initially  identified  as  unknown,  paired  with  an  air  defense  weapon,  and  later 
identified  as  hostile  (from  Diagram  Twelve). 

Diagram  Eleven  shows  a  number  of  outcomes  for  the  engagement  of  a  pre¬ 
mission  hostile  aircraft.  A  pre-mission  hostile  aircraft,  which  has  been 
identified  as  a  hostile  bomber  or  fighter  and  paired  with  an  air  defense  wea¬ 
pon,  may:  be  engaged  and  destroyed;  be  damaged  in  an  engagement  and  subse¬ 
quently  re-engaged  and  destroyed,  escape  re-engagement,  or  escape  from  the 
ADR  without  being  re-engaged;  escape  from  the  ADR  due  to  a  missed  engagement; 
escape  an  engagement  and  subsequently  escape  from  the  ADR  without  being 
re-engaged,  complete  its  mission  and  escape  from  the  ADR  without  being 
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re-engaged,  complete  its  mission  and  be  paired  with  an  air  defense  weapon 
for  re-engagement,  or  be  re-engaged  prior  to  completing  Its  mission.  A  pre¬ 
mission  hostile  aircraft  which  escapes  an  engagement  and  completes  Its  mission 
becomes  a  post-mission  hostile.  The  subsequent  prosecution  of  this  post- 
mission  hostile  aircraft,  if  It  occurs,  is  depicted  in  Diagram  Ten. 

4.5.8  Diagram  Twelve 

Diagram  Twelve  represents  the  outcomes  for  weapon  target  pairings  In 
which  the  nationality  of  the  target  is  unknown.  Diagram  Twelve  represents 
eight  types  of  targets:  post-mission  hostile  aircraft  identified  as  unknown 
bombers,  pre-mission  hostile  aircraft  identified  as  unknown  bombers,  false 
targets  identified  as  unknown  bombers,  friendly  aircraft  identified  as  unknown 
bombers,  post-mission  hostile  aircraft  Identified  as  unknown  fighters,  pre¬ 
mission  hostile  aircraft  identified  as  unknown  fighters,  false  targets  identi¬ 
fied  as  unknown  fighters,  friendly  aircraft  identified  as  unknown  fighters. 

There  are  four  possible  outcomes:  the  unknown  aircraft  may  be  identified 
as  friendly  and  be  allowed  to  safely  exit;  it  may  be  identified  as  hostile  and 
prosecuted;  it  may  be  identified  as  a  false  target  and  dropped  from  the  data¬ 
base;  or,  it  may  leave  the  region  without  being  further  identified.  The  pros¬ 
ecution  of  any  target  which  is  identified  as  hostile  is  depicted  in  one  of 
four  diagrams:  Diagram  Ten  if  the  target  is  a  post-mission  hostile;  Diagram 
Eleven  if  the  target  is  a  pre-mission  hostile;  Diagram  Thirteen  if  it  is  a 
false  target;  or,  Diagram  Fourteen  if  it  is  a  friendly. 

The  probability  that  an  unknown  bomber  or  fighter  will  be  identified 
as  friendly,  hostile,  or  false,  or  leave  without  being  further  identified, 
depends  on  what  type  of  target  it  is  and  on  the  rules  of  engagement.  For 
instance,  if  the  rules  of  engagement  state  that  an  unknown  target  must  be  vis¬ 
ually  identified  before  it  can  be  prosecuted,  the  probability  that  an  unknown 
hostile  will  be  identified  as  hostile  is  fairly  high;  likewise,  the  probabil¬ 
ity  that  an  unknown  friendly  will  be  identified  as  friendly  is  high  under 
these  rules  of  engagement.  If,  however,  the  rules  of  engagement  state  that 
after  some  specified  amount  of  time  an  unknown  aircraft  will  be  assumed  to  be 
hostile  and  can  then  be  prosecuted,  the  probability  that  an  unknown  target 
will  be  identified  as  hostile  will  be  close  to  1.0  for  both  hostile  aircraft 
and  friendly  aircraft.  Thus,  Diagram  Twelve  can  be  used  to  represent  a  vari¬ 
ety  of  scenarios. 


4.5.9  Diagram  Thirteen 


Diagram  Thirteen  represents  the  air  defense  system's  engagement  of  false 
targets  that  have  been  identified  as  hostile  bombers  and  fighters  by  the  air 
defense  system.  These  two  populations,  false  targets  identified  as  hostile 
bombers  false  identified  as  hostile  fighters,  come  from  two  tran¬ 

sitions.  Diagram  Thirteen  may  represent  the  first  (or  subsequent)  "engage¬ 
ment”  of  false  targets  which  have  been  identified  as  hostile  bombers  and 
fighters  (from  Diagram  Nine);  or,  false  targets  which  were  initially 


m 


r.  ir.ru  r. 


JW 


HR: 


identified  as  unknown,  paired  with  air  defense  weapons,  and  later  identified 
as  hostile  (from  Diagram  Twelve). 

Diagram  Thirteen  shows  four  possible  outcomes  for  the  engagement  of  a 
false  target  identified  as  a  hostile  bomber  or  fighter:  it  may  be  identified 
as  a  false  target  and  dropped  from  the  database;  it  may  stop  being  generated 
before  it  can  be  re-identified;  or  it  may  "escape  an  engagement"  (that  is,  it 
may  continue  to  be  generated  and  keep  an  air  defense  weapon  busy),  and  subse¬ 
quently  stop  being  generated  or  be  paired  with  an  air  defense  weapon  for  re¬ 
engagement  (thus,  potentially  wasting  SAMs  or  fighter-interceptor  time). 

4.5.10  Diagram  Fourteen 

Diagram  Fourteen  represents  the  air  defense  system's  engagement  of 
friendly  aircraft  that  have  been  identified  as  hostile  bombers  and  fighters 
by  the  air  defense  system.  These  two  populations,  friendly  aircraft  identi¬ 
fied  as  hostile  bombers  and  friendly  aircraft  identified  as  hostile  fighters, 
come  from  two  transitions.  Diagram  Fourteen  may  represent  the  first  (or  sub¬ 
sequent)  engagement  of  friendly  aircraft  which  have  been  identified  as  hostile 
bombers  and  fighters  (from  Diagram  Nine);  or,  friendly  aircraft  which  were 
initially  identified  as  unknown,  paired  with  air  defense  weapons,  and  later 
identified  as  hostile  (from  Diagram  Twelve). 

The  engagement  of  a  friendly  aircraft  by  the  air  defense  system  can 
result  in  a  number  of  possible  outcomes  as  shown  in  Diagram  Fourteen.  A 
friendly  aircraft,  which  has  bepn  paired  with  an  air  defense  weapon  for  en¬ 
gagement  may:  be  damaged  in  an  engagement  and  subsequently  re-engaged  and 
destroyed,  escape  re-engagement  and  exit  from  the  ADR,  exit  from  the  ADR  with¬ 
out  being  re-engaged,  or  be  identified  as  friendly  and  allowed  to  exit  from 
the  ADR;  engaged  and  destroyed;  exit  from  the  ADR  due  to  a  missed  engagement; 
be  identified  as  friendly  and  allowed  to  exit  from  the  ADR;  or,  escape  an 
engagement  and  subsequently  escape  re-engagement  and  exit  from  the  ADR,  exit 
from  the  ADR  without  being  re-engaged,  be  identified  as  friendly  and  allowed 
to  exit  from  the  ADR,  or  be  re-engaged. 


4.6  LEVEL  V 

The  diagrams  in  Level  V  do  not  themselves  comprise  a  complete  picture  of 
the  air  defense  system  (as  do  Levels  I  through  IV).  Rather,  each  diagram  at 
this  level  presents  an  expansion  of  some  part  of  a  diagram  in  Level  IV.  The 
relationship  between  the  diagrams  is  shown  in  Fig.  4-16. 


4.6.1  Diagram  Fifteen 

Diagram  Fifteen  gives  more  detail  on  the  generation  of  false  targets 
(spoofing).  It  shf-,0  that,  as  hostile  aircraft  (shaded  in  the  diagram)  enter 
the  region  they  will  emoloy  EW  assets  (on  board  or  escort)  which  will  generate 
some  number  of  false  targets.  In  addition,  ground-based  enemy  EW  assets  from 
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beyond  the  FEBA  will  also  generate  false  targets.  These  false  targets  will 
die  away  at  a  rate  determined  by  the  nature  of  the  false  target  generation 
(jamming,  chaff,  decoys,  etc.)* 

If  false  targets  continue  to  be  propagated,  they  may  be  detected  by  the 
air  surveillance  assets  of  the  air  defense  system.  Note  that  the  two  arc- 
transition-delay  combinations  associated  with  detection  in  Diagram  Fifteen, 
each  represent  three  arc-transition-delay  combinations  relating  to  the  type 
of  air  surveillance  asset  used  in  detection.  These  three  combinations  are 
discussed  more  explicitly  in  Diagram  Sixteen.  For  simplicity,  we  combine  the 
two  populations  of  false  targets,  those  generated  by  hostile  airborne  ECM 
and  those  generated  by  hostile  ground-based  ECM,  into  one  population  upon 
detection . 


A. 6. 2  Diagram  Sixteen 


Diagram  Sixteen  presents  more  details  of  the  detection  process;  the  dia¬ 
gram  Indicates  that  targets  may  be  detected  by  Electronic  Support  Measures 
(ESM),  by  active  sensors,  such  as  radar,  or  by  other  surveillance  assets  which 
can  be  identified  in  further  detail  where  needed.  As  before,  the  dotted  line 
means  that  the  surveillance  assets  remain  available  as  targets  are  detected, 
but  some  assets  must  be  available  for  the  detections  to  occur. 

Diagram  Sixteen  represents  the  detection  by  the  individual  air  surveil¬ 
lance  assets  of  five  classes  of  targets.  The  targets  being  detected  are  post¬ 
mission  hostile  aircraft,  pre-mission  hostile  aircraft,  false  targets  genera¬ 
ted  by  hostile  airborne  ECM,  false  targets  general -i  by  hostile  ground-based 
ECM,  and  friendly  aircraft.  As  in  Diagram  Fifteen,  the  two  populations  of 
false  targets,  those  generated  by  hostile  airborne  ECM  and  those  generated 
by  hostile  ground-based  ECM,  are  combined  into  a  single  population  upon 
detection. 


4.6.3  Diagram  Seventeen 

Diagram  Seventeen  presents  more  details  of  the  identification  process. 

In  this  representation  a  target  may  be  identified  by  nationality  (i.e., 

Friend,  Foe,  or  Neutral)  by  electronic  (cooperative  or  non-cooperative)  means, 
by  procedural  methods  (essentially  clerical  means),  or  by  consulting  outside 
sources,  such  as  Intel,  other  command  posts,  etc. 

The  electronic  means  available  to  the  air  defense  system  for  target 
identification  include  ESM  asset3,  IFF  assets  (transponders  such  rs  Mark  XII), 
and  radio;  again,  the  dotted  line  means  that  there  assets  remain  available  as 
targets  are  identified  but  some  asset  must  be  available  for  identification  to 
occur.  These  different  assets  can  be  represented  separately  as  needed. 

The  target  may  be  identified  because  its  flight  matches  the  characteris¬ 
tics  of  some  target  on  a  list  of  expected  targets.  in  the  tactical  situation 
the  Movements  and  Identification  (M&I. )  section  keeps  a  database  of  recorded 
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flight  plans,  safe  corridors,  emergency  flight  patterns,  etc.,  of  friendly 
aircraft.  We  represent  all  of  this  data  as  a  list  of  expected  targets;  if  the 
actual  target  matches  some  expected  target  the  aircraft  is  identified. 

Likewise  intelligence  sources  may  have  information  on  expected  targets; 
again,  if  the  flights  match,  the  target  is  identified. 

In  this  representation,  if  a  target  is  not  identified  by  any  resource,  it 
goes  forward  as  an  unknown.  Depending  on  the  Rules  of  Engagement,  an  uniden¬ 
tified  target  might  be  designated  hostile. 

This  representation  assumes  that  the  probabilities  (proportions)  of 
identification  into  the  different  classes  will  be  different  for  each  resource. 
(Thus  M&I  would  identify  friendly  targets  almost  entirely,  as  would  IFF  and 
radio.  ESM  might  identify  mainly  hostile  targets,  etc.). 

Note  that  a  target  may  "leave  the  system"  before  it  is  identified  either 
by  physically  leaving  the  region  or  because  the  system  loses  the  target  track. 
Finally,  note  that  at  this  level,  if  a  target  is  identified  as  friendly, 
whether  it  is  or  not,  it  eventually  leaves  the  system  and  no  further  proces¬ 
sing  is  done.  Diagram  Seventeen  represents  the  identification  of  four  groups 
of  targets:  post-mission  hostile  aircraft,  pre-mission  hostile  aircraft, 
false  targets,  and  friendly  aircraft. 

<r . 6 . 4  Diagram  Eighteen 

Diagram  Eighteen  is  similar  to  Diagram  Seventeen  and  represents  the  com¬ 
mon  ways  a  target  identified  as  hostile  or  unknown  can  be  identified  by  type; 
it  may  be  identified  by  ESM  assets,  by  other  non-cooperative  techniques,  or 
by  other  sources.  As  before,  the  dotted  line  means  that  the  electronic  assets 
are  necessary  for  those  identifications  to  occur  but  do  not  become  unavailable 
as  identifications  do  occur;  information  from  other  sources  Is  represented  as 
a  list  of  expected  targets. 

The  attempt  to  identify  the  target  by  type  may  conclude  that  the  target 
is  a  false  target  or  that  it  is  in  fact  friendly;  otherwise  it  will  be  iden¬ 
tified  as  a  bomber  or  a  fighter.  [These  classifications  should  be  seen  as 
illustrative;  others,  e.g. ,  cruise  missiles  or  helicopters,  can  be  introduced 
as  needed].  This  representation  assumes  that  a  target  that  cannot  be  identi¬ 
fied  by  type  will  be  assumed  to  be  a  bomber. 

Diagram  Eighteen  represents  the  identification  by  type  of  eight  groups 
of  targets:  post-mission  hostile  aircraft  identified  as  unknown,  pre-mission 
hostile  aircraft  identified  as  unknown,  false  targets  identified  as  unknown, 
friendly  aircraft  identified  as  unknown,  post-mission  hostile  aircraft  identi¬ 
fied  as  hostile,  pre-mission  hostile  aircraft  identified  as  hostile,  false 
targets  identified  as  hostile,  and  friendly  aircraft  identified  as  hostile. 

Note  that  the  transition  entering  Diagram  Eighteen  represents  one  tran¬ 
sition  for  each  of  the  first  four  groups  of  targets;  specifically,  targets  not 


identified  by  air  defense  assets  and  thus  classified  as  unknown.  For  each  of 
the  second  four  groups  of  targets,  however,  it  represents  three  transitions; 
specifically,  identified  as  hostile  by  ESM,  identified  as  hostile  by  other 
non-cooperate  techniques,  and  identified  as  hostile  by  other  sources.  Concom¬ 
itantly,  there  is  one  set  of  delays  associated  with  this  transition  for  each 
of  the  first  four  target  groups  and  three  sets  of  delays  for  each  of  the  last 
four  target  groups. 


4.6.5  Diagram  Nineteen 


Diagram  Nineteen  presents  further  detail  about  weapon-target  pairing. 

A  target  will  either  be  assigned  to  a  friendly  interceptor  or  to  an  available 
SAM  site.  This  representation  makes  no  attempt  to  indicate  how  the  alloca¬ 
tion  will  be  made.  The  Rules  of  Engagement  (ROE)  may  specify  which  is  the 
preferred  allocation  for  some  targets:  for  example,  in  some  situations  an 
unknown  target  would  always  be  paired  with  a  friendly  interceptor,  to  avoid 
the  possibility  of  fratricide. 

Diagram  Nineteen  represents  weapon-target  pairings  for  sixteen  groups  of 
targets:  post-mission  hostile  aircraft  identified  as  unknown  bombers,  pre¬ 

mission  hostile  aircraft  identified  as  unknown  bombers,  false  targets  iden¬ 
tified  as  unknown  bombers,  friendly  aircraft  identified  as  unknown  bombers, 
post-mission  hostile  aircraft  identified  as  hostile  bombers,  pre-mission  hos¬ 
tile  aircraft  identified  as  hostile  bombers,  false  targets  identified  as  hos¬ 
tile  bombers,  friendly  aircraft  identified  as  hostile  bombers,  post-mission 
hostile  aircraft  identified  as  unknown  fighters,  pre-mission  hostile  aircraft 
identified  as  unknown  fighters,  false  targets  identified  as  unknown  fighters, 
friendly  aircraft  identified  as  unknown  fighters,  post-mission  hostile  air¬ 
craft  identified  as  hostile  fighters,  pre-mission  hostile  aircraft  identified 
as  hostile  fighters,  false  targets  identified  as  hostile  fighters,  and 
friendly  aircraft  identified  as  hostile  fighters. 

ii'otc  that  there  are  four  entering  transitions  for  bombers  and  three  for 
fighters.  This  is  due  to  the  assumption  made  in  this  representation  that  tar¬ 
gets  not  identified  by  type  are  assumed  to  be  bombers.  Likewise,  there  is  a 
fourth  set  of  time  delays  associated  with  bombers. 


4.6.6  Diagram  Twenty 

Diagram  Twenty  presents  greater  detail  of  the  engagement  between  an  air 
defense  weapon  and  a  target.  In  this  representation  there  are  six  possible 
outcomes:  the  weapon  damages  the  target,  the  weapon  destroys  the  target, 

both  the  weapon  and  target  escape  the  engagement,  a  missed  engagement  occurs 
(weapon  and  target  remain  undamaged),  both  weapon  and  target  are  destroyed, 
and  the  target  destroys  the  weapon.  In  the  first  four  cases,  the  air  defense 
weapon  becomes  available  for  further  weapon-target  pairings  after  some  delay 
required  for  the  logistics  cycle. 
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Note  that  for  false  targets  the  fourth  outcome  (i.e.,  missed  engagement) 
is  the  only  possible  outcome.  This  will  be  indicated  by  appropriate  probabil¬ 
ities.  The  obvious  significance  of  such  an  event  is  that  it  results  in  the 
introduction  of  added  time  delays  in  the  command  and  control  process  as  well 
as  increased  system  load  and  waste  of  resources. 

Diagram  Twenty  represents  engagements  for  thirty-two  groups  of  targets: 
post-mission  hostile  aircraft  identified  as  unknown  bombers  and  paired  with 
SAM  batteries,  pre-mission  hostile  aircraft  identified  as  unknown  bombers  and 
paired  with  SAM  batteries,  false  targets  identified  as  unknown  bombers  and 
paired  with  SAM  batteries,  friendly  aircraft  identified  as  unknown  bombers  and 
paired  with  SAM  batteries,  post-mission  hostile  aircraft  identified  as  hostile 
bombers  and  paired  with  SAM  batteries,  pre-mission  hostile  aircraft  identified 
as  hostile  bombers  and  paired  with  SAM  batteries,  false  targets  identified  as 
hostile  bombers  and  paired  with  SAM  batteries,  friendly  aircraft  identified  as 
hostile  bombers  and  paired  with  SAM  batteries,  post-mission  hostile  aircraft 
identified  as  unknown  bombers  and  paired  with  fighters,  pre-mission  hostile 
aircraft  identified  as  unknown  bombers  and  paired  with  fighters,  false  targets 
identified  as  unknown  bombers  and  paired  with  fighters,  friendly  aircraft 
identified  as  unknown  bombers  and  paired  with  fighters,  post-mission  hostile 
aircraft  Identified  as  hostile  bombers  and  paired  with  fighters,  pre-mission 
hostile  aircraft  identified  as  hostile  bombers  and  paired  with  fighters,  false 
targets  identified  as  hostile  bombers  and  paired  with  fighters,  friendly  air¬ 
craft  identified  as  hostile  bombers  and  paired  with  fighters,  post-mission 
hostile  aircraft  identified  as  unknown  fighters  and  paired  with  SAM  batteries, 
false  targets  identified  as  unknown  fighters  and  paired  with  SAM  batteries, 
friendly  aircraft  identified  as  unknown  fighters  and  paired  with  SAM  batter¬ 
ies,  post-mission  hostile  aircraft  identified  as  hostile  fighters  and  paired 
with  SAM  batteries,  pre-mission  hostile  aircraft  identified  as  hostile  fight¬ 
ers  and  paired  with  SAM  batteries,  false  targets  identified  as  hostile  fight¬ 
ers  and  paired  with  SAM  batteries,  friendly  aircraft  identified  as  hostile 
fighters  and  paired  with  SAM  batteries,  post-mission  hostile  aircraft  identi¬ 
fied  as  unknown  fighters  and  paired  with  fighters,  pre-mission  hostile  air¬ 
craft  identified  as  unknown  fighters  and  paired  with  fighters,  false  targets 
identified  as  unknown  fighters  and  paired  with  fighters,  friendly  aircraft 
identified  as  unknown  fighters  and  paired  with  fighters,  post-mission  hostile 
aircraft  identified  as  hostile  fighters  and  paired  with  fighters,  pre-mission 
hostile  aircraft  identified  as  hostile  fighters  and  paired  with  fighters, 
false  targets  identified  as  hostile  fighters  and  paired  with  fighters,  and 
friendly  aircraft  identified  as  hostile  fighters  and  paired  with  fighters. 


4.7  SUPPLEMENTARY  DIAGRAMS 

Diagrams  Twenty-one  through  Twenty-three  represent  processes  that  occur 
at  various  places  throughout  the  hierarchy  of  the  air  defense  system.  For 
simplicity,  we  excluded  these  processes  in  the  foregoing  discussion.  We 
include  them  here  for  completeness.  As  discussed  below,  these  diagrams  may  be 
thought  of  as  overlays  to  various  sections  of  the  diagrams  in  Levels  I  -  V. 
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Diagram  Twenty-one  shows  that  the  process  of  communication  requires  com¬ 
munications  resources;  when  communication  is  complete  the  resources  again 
become  available.  Resources  may  also  be  unavailable  due  to  hostile  jamming, 
which  we  represent  as  the  capability  to  disable  a  given  number  of  communica¬ 
tions  assets.  These  assets  become  available  again  when  jamming  ceases  or  when 
ECCM  is  successfully  applied. 

This  diagram  applies  equally  to  voice  communication  or  to  data  communica¬ 
tion,  and  may  be  thought  of  as  an  overlay  whenever  a  population  of  communica¬ 
tions  assets  occurs. 

4.7.2  Diagrams  Twenty-Two  and  Twenty-Three 

In  the  foregoing  discussion,  the  surface-to-air  missiles  (SAMs)  were 
implicitly  assumed  to  be  high-and-medium-altitude  surface-to-air  missiles 
(HIMADs),  such  as  HAWK  or  PATRIOT.  These  are  the  missile  batteries  that  oper¬ 
ate  semi-autonoraously ,  having  a  data  link  to  the  Control  and  Reporting  Center 
(CRC)  of  the  air  defense  system.  That  is,  the  air  situation  picture  that  is 
maintained  by  the  surveillance  subsystem  of  the  air  defense  system  is  avail¬ 
able  to  the  operators  of  these  weapons  systems. 

There  is  another  class  of  surface-to-air  missiles  intended  for  short 
range  air  defense  (SHORAD) .  These  are  a  diverse  group  of  weapons,  shoulder- 
mounted,  such  as  STINGER,  jeep-mounted,  etc.,  that  move  with  the  ground  troops 
they  are  defending.  These  missiles  have  no  data  link  to  the  air  picture  being 
maintained  by  the  CRC;  they  are  sometimes  allocated  targets  by  voice  communi¬ 
cations,  but  generally  they  operate  autonomously,  attacking  aircraft  that 
appear  to  have  hostile  intent. 


Diagram  Twenty-Two 

Diagram  Twenty-two  (a)  shows  that  any  population  of  aircraft  is  poten¬ 
tially  subject  to  engagement  by  SHORAD  surface-to-air  missiles.  The  engage¬ 
ment  may  have  the  same  set  of  four  outcomes  as  shown  in  Diagram  Twenty. 
Diagram  Twenty-two  (b)  shows  a  much  simpler  representation  of  the  same  proc¬ 
ess:  if  the  model  being  developed  has  no  need  to  keep  track  of  SHORAD  assets, 

then  we  may  represent  any  population  of  aircraft  as  being  destroyed  at  some 
rate  by  SHORAD  resources.  Diagrams  Twenty-two  (a)  and  (b)  may  be  thought  of 
as  overlays  on  higher  level  diagrams  wherever  a  population  of  aircraft 
appears • 
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L)  AIRCRAFT  DESTROYS  SHORAD  DESOURCE 

2)  BOTH  AIRCRAFT  &  SHORAD  RESOURCE  ESCAPE 

3)  BOTH  DESTROYED 

4)  SHORAD  RESOURCE  DESTROYS  AIRCRAFT 
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Figure  4-24.  Supplement  -  Diagram  Twenty-Two  (a  &  b) 


Diagram  Twenty-Three 


Diagram  Twenty-three  illustrates  the  more  complicated  situation  that 
occurs  when  SHORAD  assets  engage  (autonomously)  aircraft  that  are  already 
subject  to  weapons-target  pairing.  In  this  representation  it  is  assumed  that 
the  SHORAD  assets  are  not  destroyed  as  a  result  of  the  engagement.  There  are 
then  three  possible  outcomes.  If  the  SHORAD  destroys  the  target,  the  weapon 
which  was  allocated  to  that  target  will  still  attempt  to  engage  the  target; 
the  result  will  appear  to  be  a  missed  engagement.  If  the  SHORAD  destroys 
the  weapon  (this  probability  is  greater  than  zero  only  when  the  weapon  is  a 
fighter),  then  the  result  may  appear  to  be  an  engagement  in  which  the  target 
destroyed  the  air  defense  weapon.  Finally,  if  the  SHORAD  destroys  neither, 
then  the  engagement  between  the  target  and  the  weapon  allocated  by  the  air 
defense  system  will  continue  as  before.  Diagram  Twenty-three  may  be  thought 
of  as  an  overlay  to  Diagrams  Ten,  Eleven,  Thirteen,  and  Fourteen,  as  well  as 
Diagram  Twenty. 


4.7.3  Representation  of  Human  Activities  in  Air  Defense 

Note  that  it  is  not  until  we  decompose  to  Level  V  and  beyond  that  it 
becomes  possible  to  consider  detailed  human  activities.  For  example,  in  Dia¬ 
gram  Nineteen  (Fig.  4-21),  the  transition  "target  paired  with  fighter”  could 
be  further  decomposed  based  on  various  ways  in  which  the  pairing  (Process) 
might  be  accomplished  to  achieve  minimum  "leakage"  (Goal)  and  the  character¬ 
istics  of  the  Target/Weapon  Assignments  Officer  (Resource),  his  degree  of 
authority  and  required  coordination  (Organization),  and  the  relevant  displays, 
controls,  processing  equipment,  and  decision  aids  (Resources)  at  his  disposal. 
A  sub-network  would  be  constructed  at  this  point,  based  on  available  data  and 
assumptions  about  how  the  function  is  (or  is  to  be)  accomplished,  to  represent 
the  detailed  human-system  interaction. 


4.8  MINIMAL  INDEPENDENT  SET  OF  MEASURES  FOR  HIERARCHY 
4.8.1  Introduction 


In  the  preceding  subsections  we  presented  a  five-level  hierarchical  rep¬ 
resentation  of  an  air  defense  system  in  Petri  net  diagrams  based  on  the  method 
of  Section  3  and  Appendix  A.  In  addition,  in  Appendix  B  we  presented  a  gen¬ 
eral  method  for  generating  all  canonical  measures  associated  with  a  Petri  net 
diagram.  Applying  the  method  of  Appendix  B  to  the  hierarchy  in  the  preceding 
subsection  yields  a  reasonable  number  of  measures  for  Level  I:  there  are  four 
probabilities,  six  rates,  four  occupancies  and  six  delays.  Subsequent  levels 
present  the  system  in  greater  detail,  so  that  at  Level  IV  there  are  much 
larger  numbers  of  measures;  at  Level  IV  there  are  253  probabilities,  193 
rates,  129  occupancies  and  348  delays. 
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Figure  4-25.  Supplement  -  Diagram  Twenty-Three 


Fortunately,  as  discussed  in  Appendix  B,  it  is  relatively  straightforward 
to  derive  an  independent  set  of  primary  measures.  This  set  is  complete,  in 
the  sense  that  all  measures  can  be  derived  from  this  independent  set,  and 
minimal,  in  the  sense  that  all  measures  cannot  be  derived  from  any  lesser 
set.  The  reduced  set  can  be  dealt  with  more  efficiently.  Subsection  A. 8. 2 
discusses  the  derivation  of  the  independent  and  minimal  set  for  any  Petri 
net.  Subsections  A. 8. 3  through  A. 8. 6  present  the  independent  set  for  Levels 
I  through  IV. 


A. 8. 2  Derivation  of  Minimal  Set 


There  are  actually  two  ways  to  derive  a  minimal  and  independent  set  of 
measures  for  each  level  of  the  hierarchy.  The  first  method  involves  deriving 
the  dependencies  at  each  level  (the  horizontal  relationships)  and  using  these 
to  eliminate  the  dependent  variables.  This  method  was  used  for  Levels  I,  II 
and  III.  The  dependencies  are  given  in  the  Appendix,  as  are  definitions  for 
all  the  measures  at  each  level. 


The  following  presents  a  more  general  method,  which  discusses  which  mea¬ 
sures  may  be  dropped  from  the  complete  set  of  measures  that  results  from  a 
Petri  net  representation  of  a  system. 


Delays 


All  delays  are  independent,  none  may  be  dropped  from  the  complete  set  of 
measures . 


Probabilities 


When  more  than  one  arc  leaves  a  place  then  one  of  the  probabilities 
associated  with  the  set  of  arcs  can  be  expressed  in  terms  of  the  others  and 
may  be  dropped. 
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Rates 


All  rates  that  can  be  expressed  as 
probability,  can  be  dropped. 


Populations 

We  may  omit  all  populations  which 
probabilities. 


the  product  of  an  upstream  rate  and  a 

*1  “  pl  *  *0 
*2  =  p2  *  *0 

an  be  recovered  from  delays,  rates  and 

N  ■  (Pl*Tl  +  ^2*t2)  *  ^0 


4.8.3  Level  1 

Figure  4-26  shows  the  diagram  for  Level  1,  Diagram  One  (Fig.  4-1),  with 
all  measures  indicated.  From  the  full  set  of  Level  I  measures,  we  suggest 
the  following  subset  of  selected  independent  measures.  Where  we  have  a  choice 
between  measures  to  omit,  we  use  the  "more-is-better"  rule  of  thumb  where 
possible.  That  is,  given  a  choice  between  two  related  measures,  we  choose  the 
measure  that  if  Increased  implies  that  the  system  is  Improving. 


Mission  Parameters 


T:  The  time  period  of  the  mission,  in  hours. 

ah:  The  arrival  rate  of  hostile  aircraft  into  the  air  defense 

region  (ADR). 

\T2:  The  arrival  rate  of  friendly  aircraft  into  the  ADR. 


Measures  of  Effectiveness 

Pj2:  The  probability  that  a  hostile  aircraft  will  be  destroyed  by 

the  air  defense  system,  given  that  it  has  entered  the  ADR. 

P13:  The  probability  that  a  friendly  aircraft  will  exit  the  ADR, 

given  that  it  has  entered  the  region. 

tj2:  The  average  delay  between  the  time  a  hostile  aircraft  enters 

the  ADR,  and  the  time  it  is  destroyed  by  the  air  defense 
system,  given  that  it  is  destroyed. 

T14:  The  average  delay  between  the  time  a  friendly  aircraft  enters 

the  ADR,  and  the  time  it  is  destroyed  by  the  air  defense 
system,  given  that  it  is  destroyed. 

A  complete  set  of  measures  for  all  five  levels  has  been  derived,  along 
with  the  relationships  among  the  measures  at  the  different  levels  (Moore 
et  al.,  1986).  Suffice  it  to  say  that  the  values  for  the  measures  of  effec¬ 
tiveness  at  the  top  level  can  be  derived  directly  by  aggregation  from  the 
most  detailed  levels,  as  described  in  Section  3. 


SECTION  5 


LESSONS  LEARNED 


As  presented  in  Sections  2,  3  and  4  of  this  report,  trial  applications 
of  various  elements  of  IAT  were  made  to  S1MC0PE,  a  simulated  C3  subsystem;  to 
the  NORAD  Missile  Warning  Center;  and  to  a  generic  Air  Defense  System.  These 
applications  resulted  in  critical  "lessons  learned,"  which  are  summarized 
below: 

During  the  SIMCOPE  application,  an  attempt  was  made  to  use  the  SHOR  para¬ 
digm  (Wohl,  198L)  as  the  basis  for  system  description  and  decomposition.  This 
attempt  was  unsuccessful,  and  both  IDEF0  and  Data  Flow  Diagrams  (DFDs)  were 
resorted  to,  with  the  latter  ultimately  being  used  as  the  primary  representa¬ 
tional  scheme  because  of  its  relative  simplicity  and  clarity.  (See  Appendix  D 
for  procedures  and  guidelines  for  using  DFDs  to  develop  IAT  data.) 

In  addition,  the  SIMCOPE  application  involved  only  skill-  and  rule-based 
behavior  ((Rasmussen  and  Rouse,  1979);  see  Volume  I  for  description  of  this 
taxonomy).  Since  no  knowledge-based  behavior  was  required  of  the  operator, 
his  tasks  in  SIMCOPE  were  not  truly  representatative  of  human  decisionmaking 
tasks  in  C3  systems.  Nonetheless,  it  was  possible  to  demonstrate  the  applica¬ 
tion  of  queuing  theory  methods  to  system  performance  analysis  and  prediction. 

In  contrast  to  SIMCOPE,  the  NORAD  Missile  Warning  Center  application  was 
a  completely  realistic  one.  Data  Flow  Diagrams  once  again  were  used  for  sys¬ 
tem  description  and  decomposition,  in  this  instance  down  to  the  third  level 
of  detail.  This  application  uncovered  the  fact  that  many  of  the  processes 
involving  human  activities  are  procedure-bound ;  that  is,  they  are  governed 
largely  by  checklists,  written  procedures,  unwritten  procedures,  and  informal 
"arrangements"  among  crew  members.  Fortunately,  much  of  this  was  found  to  be 
routine  and  rule-based,  and  therefore  easily  modeled.  While  the  data  amassed 
during  this  application  could  support  several  types  of  analyses,  only  the 
simplest  of  PERT/CPM  analysis  methods  was  considered  in  this  case. 

Another  lesson  learned  at  NORAD  was  the  fact  that  at  these  higher  levels 
of  command  authority  and  responsibility,  a  great  deal  of  human  activity  is 
involved  in  briefing;  that  is,  in  aggregating  or  packaging  (chunking)  infor¬ 
mation  for  easier  and  more  rapid  "digestion"  at  the  next  higher  level  of  com¬ 
mand.  This  almost  always  involved  situation  assessment  and  hypothesis  formu¬ 
lation,  as  well  as  option  identification  activities.  The  briefing  would  then 
take  the  form  of  "Here's  the  situation,  here's  what  we  think  is  happening, 
here's  the  status  of  our  own  systems  and  forces,  here  are  the  things  we  can 
do,  and  hete's  what  looks  best  under  the  circumstances.” 


The  main  difficulty  for  the  analyst  at  NORAD  was  in  extracting  the 
unwritten  procedures  from  the  crew  members,  i.e.,  the  things  that  they  do 
"automatically"  as  a  trained  crew  or  "expert  team."  This  required  that  the 
analyst  be,  in  effect,  a  "knowledge  engineer."  Without  the  aid  of  the  sophis¬ 
ticated  artificial  intelligence  techniques  available  to  trained  knowledge 
engineers,  this  became  a  difficult  and  time-consuming  task. 

The  Air  Defense  application,  which  was  done  partly  under  the  aegis  of 
DCA  and  JCS,  was  based  on  the  representational  and  decomposition  requirements 
described  in  Volume  I  of  this  report.  It  was  also  the  first  attempt  to  apply 
the  extended  Petri  net  methodology  (STAPNs)  to  a  system  of  realistic  capa¬ 
bility,  complexity,  and  size,  using  a  completely  "top-down"  approach. 

The  results  clearly  indicated  that  STAPNs  could  be  used  to  describe  all 
of  the  activities  in  both  in  C3  systems  and  the  weapon  systems  which  it  con¬ 
trols.  The  existence  of  a  complete,  nested  set  of  measures  of  both  system 
performance  and  military  effectiveness  was  also  demonstrated. 

While  the  decomposition  was  taken  down  to  the  fifth  level,  the  resulting 
complexity  is  exemplified  by  the  approximately  1000  measures  identified  (Moore 
et  al.,  1986).  However,  at  least  one  and  perhaps  as  many  as  three  or  four 
more  levels  of  detail  would  have  to  be  developed  in  specific  subsystem  areas 
in  order  to  provide  the  requisite  information  about  human  decision  functions 
for  modeling  and  prediction  purposes.  But  since  such  details  can  be  modeled 
using  STAPNs,  as  shown  in  Volume  I,  one  would  anticipate  little  or  no  problem 
In  this  regard  other  than  the  additional  effort  required.  In  any  case,  there 
is  no  shortcut  to  dealing  with  the  complexity  inherent  in  manned  C3  systems. 

All  cf  the  applications  to  date  involved  manual  paper-and-pencil  activi¬ 
ties,  which  strongly  indicated  that  the  labor-intensiveness  of  such  activities 
for  future  applications  to  C3  systems  would  be  prohibitive,  and  that  automated 
aids  for  IAT  would  have  to  be  developed.  This  fact  was  a  major  driver  in  the 
development  of  the  STAPN  representation  and  modeling  approach,  as  well  as  the 
Box  Node  aggregation  primitive  and  the  frame/slot  data  management  technique 
noted  above. 


APPENDIX  A 

THE  QUEUING  MODEL  FOR  SIMCOPE 

A .  1  THE  SIMCOPE  OPERATIONAL  ENVIRONMENT:  GOALS/ORGANIZATION/PROCESSES/ 
RESOURCES 

The  focus  of  SIMCOPE  is  on  the  Missile  Warning  Officer  (MWO)  in  the  CWC, 
who  receives  messages  from  surveillance  systems  that  monitor  missile  launch 
activities  ('’events").  The  MWO  must  acknowledge  messages,  determine  what  the 
events  are  associated  with  the  messages,  generate  reports  about  the  events, 
and  forward  them  to  the  Command  Defense  Center  (CDC). 

For  each  detected  launch  event,  there  may  be  three  messages: 

1.  ADS-1  (the  first  indication  from  the  Advanced  Detection 
System,  ADS). 

2.  ADS- 2  (the  second  indication  from  ADS). 

3.  BSS  (indication  from  the  Barrier  Surveillance  System  that  an 
object  has  actually  crossed  the  blue-side  coastline). 

Other  messages  of  interest  describe  non- launch  events.  Note  that  messages 
describing  system  status  and  intelligence  are  important,  but  should  be  consid¬ 
ered  independently  from  the  primary  processing  (message-handling)  of  launch- 
related  events. 

Figure  A-l,  presented  earlier  as  Fig.  2-2,  is  included  in  this  Appendix 
as  a  reference  diagram  to  show  data  flow  of  message  handling  in  SIMCOPE. 


A . 1 . 1  Description  and  Analysis  of  Mission  Events 


Figure  A-2  portrays  the  structure  of  mission  events  for  SIMCOPE.  Figure 
A-3  Illustrates  how  frame  notation  can  be  used  to  describe  the  overall  sce¬ 
nario  that  drives  the  system:  Attack  Warning,  Threat  Assessment,  and  Damage 
Estimation  are  the  three  critical  components  of  the  scenario. 

For  purposes  of  analysis  using  IAT,  no  reaction  by  the  enemy  has  been 
assumed.  Therefore,  there  are  four  output  events  which  are  generated  in  an 
essentially  open-loop  fashion: 
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Figure  A-la.  DeMarco  Diagram  Used  in  SIMCOPE  Validation:  Context 
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Figure  A-lb.  DeMarco  Diagram  Used  in  SIMCOPE  Validation:  Overall  Data  Flow 
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Figure  A-2.  Tree  Structure  Showing  Mission  Events 
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Figure  A-3.  SIMCOPE  Mission  Events  Frame:  Example  Showing  Use  of  Frame 
Notation  to  Capture  Properties  of  (Mission)  Events 
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If  the  prevailing  condition  in  the  system  is  peacetime  monitoring,  prior 
to  executing  the  scenario,  the  four  output  events  listed  above  are  analyzed 
as  "disturbances"  to  the  status  quo.  Other  than  changing  the  prevailing  con¬ 
ditions  or  postulating  enemy  (threat)  reactions,  there  are  only  two  contin¬ 
gencies  which  could  affect  how  the  four  output  events  are  generated: 

o  Equipment  outage(s) 

•  Erroneous  reports  or  report  contents 


1  A . 1 . 2  Consequences  of  Executing  the  Mission  Scenario 

!  When  the  scenario  is  executed,  the  expected  result  will  be  to  generate 

I  the  four  reports  listed  above.  However,  there  are  two  other  types  of  events 

that  should  be  noted: 

1.  Inappropriate  Events  (false  alarms) 

2.  Undetectable  Events  (misses) 

(There  are  also  mission  events  which  might  affect  the  work  environment  and 
the  stress  level  under  crisis  conditions,  but  these  types  of  environmental 
stressors  will  not  be  considered  in  the  analysis  that  follows.) 

A. 2  ASSUMPTIONS  AND  STRUCTURE  OF  THE  MODEL 

1.  Each  message  stream  is  a  process  with  an  independent  Poisson 
arrival  (exponential  Interarrival  time).* 

!2.  The  expected  value  of  the  arrival  rates  can  be  used  to  charac¬ 
terize  each  message  stream. 

3.  Data  required  to  establish  values  for  arrival  rates  can  be 
collected  from  the  SIMCOPE  mission  environment. 


*In  the  actual  SIMCOPE  scenario,  the  three  messages  would  not  be  strictly 
independent;  arrival  of  any  ADS-1  message  would  imply  that  an  ADS-2  and  pos¬ 
sibly  a  BSS  message  would  be  arriving  at  some  future  time.  These  complica¬ 
tions  are  not  taken  into  account  in  the  preliminary  analysis  presented  here. 
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A.  There  is  a  separate  server  for  each  process  shown  in  Fig.  A-lb. 

5.  The  utilization  factor  (p)  for  each  process  remains  less  than  1. 

A. 2.1  Expressions  to  Describe  Arrival  and  Service  Rates 

Notations  for  the  arrival  rates  and  service  rates  of  interest  appear  below 
Xg  =  Arrival  rate  for  system  status  messages 

Xj  =  Arrival  rate  for  Intelligence  messages 

XadsI  “  Arrival  rate  for  ADS1  messages 
Xads2  "  Arrival  rate  for  ADS2  messages 
X ggg  “  Arrival  rate  for  BSS  messages 

Pack  3  Acknowledge  service  rate 

UASN  =  Assign  service  rate 

prep  “  Report  service  rate 

Given  the  assumption  of  Poisson  arrivals,  the  overall  message  arrival  rate  for 
the  system  is  the  sum  of  individual  arrival  rates: 

XA  *  xs  +  X1  +  XADS1  +  XADS2  +  XBSS  .  (1) 

Arrival  rates  for  t’'e  "Assign"  and  "Report"  queues  can  be  expressed  similarly 
as  the  sum  of  message  arrival  rates,  once  we  observe  that: 

•  Only  event-related  messages  pass  to  the  Assign  queue. 

•  All  messages  going  to  the  Assign  queue  also  go  to  the  Report 
queue  (see  Fig.  A-lb  for  data  flow). 

Arrival  rate  for  Assign  queue: 

XASN  “  XADS1  +  XADS2  +  XBSS  *  (2) 

Arrival  rate  for  Report  queue: 

XREP  =  XADS’  +  XADS2  +  XBSS  *  (3) 
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Since  all  event  messages  must  pass  through  all  three  processes  in  the 
system,  the  time  any  message  might  be  expected  to  remain  in  the  system  is  the 
sum  of  the  time  spent  in  each  process.  From  expressions  (2)  and  (3)  above, 
and  from  Table  4-2  in  Section  4, 


where 


w  =  1/(PACK  "  xa)  +  i/^ASN  ~  xe)  +  1/ (bREP  "  xe)  > 


XE  =  XADS1  +  XADS2  +  XBSS 


A. 2. 3  Estimating  Delays  and  Queue  Length 

In  the  SIMCOPE  example  considered  here,  delay  in  the  system  can  be  esti¬ 
mated  as  the  sum  of  the  expected  service  times: 


l/^ACK  +  ^ASN  +  i/bREP  • 


This  estimate  assumes  only  one  "critical  path"  —  viz.,  through  all  three 
processes.  An  alternative  method  to  predict  delays  would  use  an  event  anal¬ 
ysis  or  CPM  (Wohl,  1984).  However,  the  queuing  theory  analysis  used  in  (6) 
above  is  preferred:  i:  the  arrival  rates  are  small  compared  to  the  service 
rate,  both  the  CPM  and  the  queuing  estimates  would  be  comparable;  but  when 
capacity  is  highly  loaded  (arrival  rates  exceed  service  capabilities),  the 
CPM  approach  would  underestimate  the  expected  values. 

The  backlog  of  reports,  or  expected  number  of  reports  in  the  Report  queue, 
provides  a  description  of  queue  length: 


!,  =  X  /(y  -X  )  .  (') 

E  ^  REP  E7 

An  efficient  system  should  have  a  small  backlog  (L  should  be  low  compared  to 
other  parameter  values).  Note,  however,  that  it  is  often  extremely  costly,  in 
terms  of  number  and  speed  of  servers,  to  maintain  a  low  value  of  L  over  long 
periods  of  continuous  service. 


A. 3  DETERMINING  SERVICE  RATES:  USING  INFORMATION  FROM  THE  STRUCTURAL  MODEL 

The  problem  of  estimating  and  predicting  service  rates  is  critical  for 
predicting  human/system  performance.  Questions  of  operator  control  and 
attention  must  be  addressed.  Control  structures,  in  turn,  depend  on  goals, 


ms 


106 


7T77W 


nromutK*  xak/ 


tM  AC  If  IWAV.V^v'jv  -"■"-  ".*  r 


f  VTi  W"t  v*  wn  yT»  w"»  rfn  «rw  «. 


organizational  policies  and  rules,  and  human  operator  capabilities  (related 
to  an  individual's  background  and  training). 


I 

l 

I 

» 

! 


i 

n 


It  is  here  that  the  four  dimensions  (GOALS,  ORGANIZATIONS, 
PROCESSES,  RESOURCES)  of  the  IAT  structural  modeling  component 
become  most  useful  in  describing  human  performance  in  the  SYSTEM. 


The  problem  of  deriving  service  rates  presents  a  clear  case  for  linking 
information  from  the  structural  model  to  assumptions  that  are  needed  to  carry 
through  with  the  queuing  theory  application. 


A . 3 . 1  Assumptions  for  Determining  Service  Rates 

There  are  two  problems  that  must  be  considered  in  determining  service 
rates : 

1.  What  is  the  effective  rate,  given  that  the  same  resource  must 
be  used  in  several  processes? 

2.  What  is  the  rate  to  perform  a  specific  task,  given  that  resource 
attention  is  devoted  to  that  task? 

The  first  problem  is  addressed  in  the  discussion  that  follows,  since  it 
describes  the  general  case  for  the  SIMCOPE  example. 


The  Effective  Rate  for  the  Acknowledge  Queue 

Based  on  the  data  flow  representations  (Figs.  5-5  through  5-7),  we  shall 
assume  that  the  conditions  listed  below  describe  the  SIMCOPE  operational 
e nvironmeuL : 

1.  Computerized  processes  are  executed  much  more  rapidly  than  are 
manual  ones. 


t 


2.  Associated  processing  delays  for  computerized  processes  are 
negligible,  and  can  be  ignored  for  purposes  of  presentation 
here . 

3.  The  human  operator  controls  the  movement  of  items  from  queue 
to  queue  and  also  controls  attention  to  processes. 

4.  The  effective  service  rate  depends  on  how  control  of  item¬ 
handling  and  attention  is  accomplished. 


107 


<.*, »«*  |j,v .♦iMiVl** 


ii.*  i.» .to' ii' 


It  is  important  to  understand  that  the  control  structure,  implicit  in  the 
assumptions  listed  above,  depends  on  GOALS  —  set  by  the  organization  in  the 
SIMCOPE  context  —  and  operator  training.  If  we  view  SIMCOPE  as  a  real-world 
manned  C3  system,  the  control  structure  would  be  realized  as  a  set  of  rules  or 
conditions  that  define  how  processing  is  to  be  organized.  The  following 
conditions  are  presumed  to  hold  for  the  SIMCOPE  example: 

C— 1 :  Keep  the  Acknowledge  queue  empty. 

C-2:  Empty  the  Assign  queue  before  working  on  reports. 

C-3:  Generating  reports  is  a  task  that  can  be  interrupted.  But, 

C-4:  Operators  must  complete  assignment  of  current  information 

before  moving  on  to  acknowledge  a  new  arrival  (of  a  message). 

Given  these  policies,  tAc^,  the  expected  time  to  service  a  message  in  the 
Acknowledge  queue,  is  the  weighted  average  of  two  terms: 

t'ACK*  time-to-acknowledge  when  the  server  is  actively  working 

on  the  Acknowledge  task;  and 

ts,  the  time-to-switch  to  the  Acknowledge  task  when  a  new  message 
arrives  with  nothing  in  the  queue. 

The  expected  time-to-acknowledge,  tAc£,  then  is  given  by  the  following: 


CACK  =  O  _  po)  c’ACK  +  po  (t'ACK  +  cs) 


-*  t'ACK  +  po  cs 


where  P0  is  the  probability  that  the  Acknowledge  queue  is  empty  (and  (1  -  PG) 
is  the  probability  that  the  server  is  busy  —  i.e.,  the  queue  is  _not  empty). 
P0  still  needs  to  be  found.  From  Table  4-2  in  Volume  I: 


po  =  i  -  Whack 


which  leaves 


=  1  _  *A  (tACK> 


lACK  =  c'ACK  +  “  XA  cACk)  cs 


(1  +  XA  ts)  tACK  =  t'ACK  + 


1 
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tACK  3  (t’ACK  +  ts)/(l  +  XA  ts) 


VACK  -  1/tACK  “  (1  +  XA  t8)/ (t*ACK  +  ts) 


is  the  effective  service  rate  for  the  queue. 


Effective  Rates  for  the  Assign  and  Report  Queues 

Recall  that  the  Assign  queue  is  considered  only  when  the  Acknowledge  queue 
is  empty.  Therefore,  service  times  will  again  be  the  weighted  average  of  the 
two  terms, 


CASN  3  Pq  C’aSN  +  (1  -  Pq)  (t'ASN  +  tb) 


t'  ASN  +  (1  “  Pq)  cb 


where 


tb  3  1/(WACK  -  *A) 


is  the  expected  time  the  Acknowledge  process  is  busy,  t'ASN  is  the  conditional 
time  to  assign  given  the  process  is  active,  and  P0  the  probability  that  the 
Acknowledge  queue  is  empty.  Hence, 


»ASN 


[t'ASN  +  O  ~  po)  cb] 


For  the  Report  queue, 


[t'REF  +  (L  ”  poA  )  tb  ] 
ASN  ASN 


(20a) 


VX  VK  V-X  v> VKiT*  J 
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CREP  *■  C'REP  +  (1  “  )  tb 

ASN  ASN 


(20b) 


where  PQ  is  the  probability  of  no  messages  in  the  Assign  queue  and  t^  is 
ASN  ASN 


the  expected  busy  period  of  the  Assign  queue: 


?/,  =  l  -  ^e/masn 

°ASN  AbN 


=  i/CUASN  -  XE) 

ASN 


At  this  point,  service  rates  and  arrival  rates  have  been  derived  for  each 
queue  in  the  system  but  since  each  still  involves  unknown  parameters,  the 
conditional  service  rates  must  be  estimated. 


A. 3. 2  Determine  Service  Rates  for  Performing  Specific  Tasks 


The  unknown  parameters  in  the  formula  for  the  Acknowledge  service  rate 
are  t'ACK,  the  expected  time  required  to  perform  the  Acknowledge  function 
when  attention  is  already  directed  to  Acknowledge,  and  ts,  the  expected  time 
required  to  switch  attention  to  Acknowledge  from  some  other  function. 


According  to  the  SIMCOPE  Subject  Instructions  (ALPHASCIENCE ,  1984),  the 
operator's  task  to  acknowledge  a  message  requires  a  single  button  press,  an 
activity  that  should  take  approximately  .5  seconds  (Woodson,  1981).  There¬ 
fore,  let  t'AcR  =  -5  seconds. 


If  the  Acknowledge  queue  is  empty  and  a  new  message  arrives,  the  subject's 
attention  is  drawn  to  the  new  message  by  either  one  or  two  cues.  (Event  mes¬ 
sages  and  emergency  status  messages  are  accompanied  by  an  audio  alarm  plus  a 
flashing  light;  intelligence  messages  and  routine  status  messages  are  cued 
with  the  flashing  light  only.)  If  we  assume  that  only  one  reaction  time 
("  0.2  seconds)  is  required  for  messages  with  audio  alarms  and  5.0  seconds 
are  required  for  the  rest,  the  expected  switch  time  is 


=  PA  (.2)  +  (1  -  PA)  (5)  -  5  -  4.8  PA 


where  PA  is  the  proportion  of  messages  accompanied  by  an  audio  alarm.  If  Agg 
is  the  arrival  rate  for  emergency  status  messages  and  Agg  is  the  rate  for 
routine  status  messages  (i.e.,  Ag  ■  Agg  +  Agg), 


no 


and 


XES  +  XADS1  +  XADS2  +  XBSS 
XI  +  XES  +  XRS  +  XADS1  +  XADS2  +  XBSS 


(24) 


PA  " 


PA  “  (XES  +  XE)/XA 


(25) 


(Recall  that  is  the  overall  arrival  rate  for  event-related  messages,  from 
expression  //I  on  p.  50.) 

All  parameters  needed  for  the  Acknowledgement  process  have  been  derived. 
However,  the  other  major  processes  —  Assigning  Event  Data  and  Generating 
Reports  —  still  have  unknown  parameters  that  must  be  developed. 


The  Assign  Queue  Service  Rate 

There  is  only  one  unknown  parameter  associated  with  the  Assign  function, 
t'^sN*  t*ie  expected  time  to  carry  out  the  Assign  task.  In  order  to  derive  a 
service  time  for  this  task,  one  needs  to  identify  subtasks  required  of  the 
human  operator,  and  their  associated  average  durations.  These  subtasks  must 
be  analyzed  to  determine  how  service  gets  accomplished  (in  the  queuing  model). 


Again,  this  case  illustrates  how  information  from  the  1AT 
structural  model  (i.e.,  decomposition  along  the  PROCESS 
dimension)  becomes  useful  in  estimating  performance. 


Figure  A-4  describes  the  "Assign  Event  Number"  process  and  identifies  the 
subprocesses  that  would  appear  in  an  IAT  structural  decomposition.  Bracketed 
numbers  ("[  ]")  indicate  estimated  times  in  seconds  for  each  operation*;  ex¬ 

pressions  denoted  by  "P"  (such  as  P0  and  Pg)  describe  branching  probabilities. 


Estimating  Edit  Time:  How  Operators  Correct  Errors  in  Assigning  Event  Data 

With  the  exception  of  the  Editing  process,  all  of  the  operations  shown  in 
Fig.  A-4  have  associated  completion  times  that  are  straightforward  to  derive 
from  the  SIMC0PE  context.  The  time  required  to  edit  an  assignment,  tg,  can  be 
estimated  as  follows. 


'•Based  on  SfMCOPE  inst 


ructions  (ALPHASCIENCE ,  1984). 


r  DETERMINE  ' 
.EVENT-NUMBER, 


PUSH 

ASSIGN  KEY 


r  push  > 

EVENT-NUMBER 
^  KEY  J 


Figure  A-4.  The  "Assign  Event  Number"  Process. 


From  the  SIMCOPE  Subject  Instructions: 

1.  There  are  two  methods  of  editing  — 

Backstepping 

Reassignment 

2.  Both  methods  are  assumed  to  take  .5  seconds  each  on  the  average. 

3.  Both  are  equally  likely,  once  an  operator  has  checked  an 
assignment . 

Figure  A-5  illustrates  the  human  operator  decision  and  identifies  the 
subprocesses  that  follow  from  the  edit  function. 
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Estimating  Time  for  the  Assign  Process 


Given  tg,  it  is  now  possible  to  estimate  the  expected  time  to  com¬ 
plete  the  entire  "Assign"  process.  From  Fig.  A-4,  it  is  clear  that  t'^gN  wiH 
be  the  sum  of  the  times  associated  with  each  sub-process,  (.5  +  .5  +  .5  +  .5], 
plus  P0  (1.0  +  tE): 


t'ASN  -  2.0  +  P0  [1.0  +  PE  (1.75)]  .  (27) 


Estimating  Time  to  Complete  Reports  (t'ggp) 

(1)  ADS-1  -  The  approach  taken  here  is  to  consider  reports  for  each  message 
type,  ADS-1,  ADS-2,  and  BSS  individually;  then  average  the  results  to  estimate 
t'ggp.  Figure  A-6  describes  the  sequence  of  processes  that  an  operator  would 
carry  out  for  the  ADS-1  report.* 

Figures  A-7,  A-8,  and  A-9  present  a  process  decomposition  of  the  opera¬ 
tions  pictured  on  Fig.  A-6.  Decomposition  is  used  for  tasks  judged  subjec¬ 
tively  to  be  more  complex  because  of  the  decision-making  that  is  required. 

The  last  operation  for  completing  the  ADS-1  report  is  Edit,  shown  in 
Fig.  A- 10,  where 

1.  Pgy  =  Probability  the  report  is  edited  (requiring  menu  selection 

from  a  CRT  display); 

2.  Each  edit  cycle  is  assumed  to  be  4.75  seconds  long; 

3.  The  probability  that  n-edit  cycles  will  be  performed  is 


P(n)  -  PED(n-l)  (i  -  PgD) 


(28) 


and 


4.  The  distribution  for  (28)  has  expected  value 


E(n)  =  1/(1  -  PgD) 


(29) 


*We  are  assuming  that  an  operator  does  NOT  return  to  "Edit"  after  once 
leaving  it. 
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LAUNCHER 
TYPE  AT 
SITE? 


RECALL  ADS? 

INTENSITY 
^  REPORT  > 


CORRELATE 
TWO  DATA 
^  ITEMS 


SELECT  ANO 
PUSH  BUTTON 


Figure  A-9.  Specifying  Launcher-Type  for  ADS-l* 


SELECT 

ITEM 


[4.25] 


SELECT 
FROM  MENU 


RETURN 
TO  AUTO 


Figure  A-10.  Edit  Sequence  for  ADS-1 


*Note  that  this  task  sequence  is  assumed  to  involve  operator  decision-making. 
Although  data  were  available  within  the  SIMCOPE  environment  to  describe  the 
task  "Specify  Confidence"  (shown  in  Figure  A-6),  data  could  not  be  obtained 
for  specifying  confidence  of  making  the  launcher-type  decision.  Hence,  no 
sub-task  called  "Specify  Confidence"  is  shown  on  Figure  A-9,  above. 
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From  Fig.  A-10  and  the  assumptions  stated  above  describing  the  edit  cycle, 
the  expected  time  it  would  take  to  complete  the  Edit  process  is: 


t ’ rn  -  4.75  £(n)  +  .5 


(where  .5  represents  the  time  needed  to  press  the  "AUTO"  button). 


Given  the  estimate  of  t'gQ  above,  we  obtain  the  expected  time  to  complete 
the  ADS-1  report: 


c' ADS-1  “  24 


4.75 

,0  +  p'ED  -  +  .5 

_1_PED 


where  p,ED  is  the  branch-probability  that  the  report  is  edited; 


P£D  is  the  probability  an  item  is  selected  from  a  CRT  menu, 
as  part  of  the  Edit  sequence  (shown  in  A-10); 


24.0  (seconds)  is  the  sum  of  the  seven  individual  task  comple¬ 
tion  times  plus  the  time  required  to  "Send,"  as  shown  in 
Fig.  A- 6. 


(2)  ADS- 2  and  (3)  BSS  -  The  approach  for  deriving  completion  times  for  the 
ADS-2  and  the  BSS  reports  is  analogous.  Figure  A-ll  shows  estimated  times 
for  each  operation  involved  in  completing  the  ADS-2  report;  Figs.  A-12  and 
A-13  present  decompositions  of  the  more  complex  tasks  required  to  generate  the 
ADS-2  report  (i.e.,  operations  that  require  the  operator  to  make  more  complex 
decisions) . 


Details  of  tasks  required  to  complete  the  BSS  report  are  presented  in 
Fig.  A-13;  the  possible-target  decision  is  diagrammed  in  Fig.  A-15.  The  logic 
for  estimating  times  in  these  cases  is  identical  to  the  previous  example  (for 
ADS-1): 


t'BSS  =  10-5  +  p ' ED 


3.0 

-  +  .5 

_1-PED 


lift 


KV7 


WWW 


WWW" 


« 


t'ED  was  obtained  as  In  the  ADS-l  sequence,  and 
P'gj)  for  ADS-l  and  ADS— 2  are  the  same. 


#  ?i02 

Figure  A— 11.  ADS-2  Report  Sequence 
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Figure 


i-l2.  Determine  Even,.  Type 


[0.5] 


Figure  A-13.  Expected  BSS 


R- 2  406 


Figure  A-15.  Possible-Target  Decision 


Predicting  Overall  Time  to  Generate  Reports 

The  expected  time  to  generate  a  report  is  the  average  of  the  times  for 
each  report  type  since  there  is  generally  one  report  of  each  type  per  sus¬ 
pected  launch  event : 


''Assuming  all  Taunch  events  will  intercept  a  region  covered  by  BSS . 
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A. 4  PREDICTING  SIMCOPE  HUMAN/SYSTEM  PERFORMANCE:  EFFECTS  OF  HEAVY  AND 
LIGHT  LOADING 

In  A. 3.1  the  following  service  time  relationships  were  derived: 


where 


"ACK 


t'ACK  +  l3 

(1  +  Aa  tg) 


CASN  ”  c'aSN  +  (l  ~  po>  cb 


tREP  ‘  C'REP  +  (‘  ‘  P»*SN)  tbASN 


1  *  XA  cACK 


tb 


tACK 


1  *  XA  CACK 


ASN 


1  -  XE  CASN 


cb 


CASN 


ASN  1  *  XE  tASN 


(35) 


(36) 

(37) 


Consider  the  Acknowledge  time  first.  The  estimate  for  the  conditional 
Acknowledge  time  ( t * aCk)  was  0*5  seconds  and  the  switch  time  (ts)  was 


XES  +  xEn 

t8  =  5.0  -  4.8  ( - )  •  (38) 

XA 

Therefore , 

XES  XE 

0.5  +  5.0  -  4.8  ( - ) 

XA 

CACK  - - •  (39) 

1  +  5.0  \k  -  4.8  (XES  +  XE) 
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From  these  derivations,  we  can  conclude  the  following  about  human/system 
performance  in  SIMCOPE: 

1  •  The  Acknowledge  Process 

As  the  proportion  of  audio-cued  arriving  messages  increases, 
Acknowledge-time  decreases. 

Recall  the  events  and  emergency  status  messages  are  both  cued 
( Xgg  and  Xg).  This  is  due,  in  part,  to  the  longer  switch  time 
associated  with  non-cued  inputs.  If  XA  is  larger  and  if 


L. 


XE  +  XES  *  XA  » 


cACK  “  *52  seconds  , 


which  suggests  that  in  such  cases  the  Acknowledge  process  would 
not  significantly  slow  processing. 


XE  +  XES 


tACK  1  +  5.0  XA 


Po  “  1  * 


5-5  XA 
1  +  5.0  XA 


For  XA  large,  P0  will  be  approximately  zero,  which  means  all 
resources  will  be  consumed  by  Acknowledge.  This  suggests  that 
this  system  could  be  subverted  by  flooding  it  with  a  large 
number  of  intelligence  or  routine  system  status  messages. 

The  Assign  Process 

Consider  the  Assign  process: 


,T77s7 y^l  ?r  7  f  \m  UTl  jrp 


tASN  ■  t'ASN  +  (!  *  po)  cb 

^ACK 

-  2.0  +  P0  [1  +  PE  (1.75)]  +  (1  -  PQ)  -  . 

po 

If  the  system  is  heavily  loaded  and  the  Acknowledge  queue  is 
nearly  always  occupied  (PQ  *  0),  then  tAg^  becomes  very  large, 
reflecting  the  fact  that  all  resources  are  devoted  to  Acknow¬ 
ledge.  If  PQ  +  1,  then  t^gfl  ■  3+PE  (1.75),  which  is  equiv¬ 
alent  to  parallel  processing  (i.e.,  separate  servers  for 
Acknowledge  and  Assign).  Given  that  the  service  time  penalty 
resulting  from  one  operator  is 


(1  -  P0)  tACK 

> 

po 

it  is  straightforward  to  predict  what  benefits  could  be  obtained 
by  adding  another  operator. 

3.  The  Generate  Report  Process 

The  estimated  time  for  generating  reports  is: 


CREP 


t' 


REP 


(i  -  p, 


“Vs*!1 


cb 


ASN 


-  17.5  +  P'ED 


3.5 

-  +  .5 

_1_PED 


+  XE  CASN 


CASN 


1  *  XE  CASN 


Again  the  effects  of  heavy  or  light  loadings  can  be  easily 
explored.  Assuming  that  the  probability  of  editing  is  quite 
small  (P'ed  "  0),  then  tEEp  ■  17.5  when  the  assignment  queue 
is  nearly  empty  (tAg^  *  0).  This  again  is  the  limit  that 
applies  if  parallel  servers  were  used.  The  time  multiplied  by 
P'ed  could  be  used  to  evaluate  the  impact  of  poor  versus  good 
operators.  For  example,  a  good  operator  might  have  a  small 
p,ED«  whHe  a  poor  operator  would  have  a  larger  value. 

Once  all  parameter  values  are  substituted,  the  time  estimates 
are  expressed  as  functions  of  the  message  arrival  rates. 
Clearly,  whether  or  not  performance  is  adequate  depends  on 
this  loading.  The  main  point,  however,  is  that  such  evalua¬ 
tion  is  quite  easy  to  do  once  the  appropriate  expressions  are 
obtained . 
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A. 5  REDESIGN  ISSUES 


The  analysis  in  this  Appendix  supports  the  following  recommendations  for 
system  design: 

1 .  Addition  of  One  or  More  Operators  — 

First-order  effects  of  manpower  changes  can  be  explored  by 
adjusting  the  appropriate  service  time  parameters.  To  see  the 
implications  of  these  changes  on  the  entire  system,  analysts 
can  use  components  of  the  IAT  structural  model  to  trace  (side) 
effects  of  staffing  changes  (RESOURCE  allocation)  on  elements 
of  ORGANIZATIONS,  GOALS,  and  PROCESSES. 

2 •  Change  in  Policy  Concerning  the  Acknowledge  Process  — 

Recall  that  an  excessive  number  of  routine  status  or  intelli¬ 
gence  messages  might  overload  the  system.  If  only  event  or 
emergency  messages  are  acknowledged,  routine  system  status  and 
intelligence  messages  are  essentially  eliminated  for  purposes 
of  this  analysis.  In  this  case,  Xes  +  Xg  =  Xa  and  cACK  would 
take  on  its  lower  bound  value  of 


tACK  = 


1  +  .2  Xa  1  +  .2  ( Xg  +  Xes) 


An  intermediate  position  would  be  to  cue  all  arrivals  with  an 
alarm.  This  would  eliminate  the  assumed  5-second  delay  asso¬ 
ciated  with  non-cued  inputs  and  t^  “  .2,  so  that 


1  +  .2  Xa 

The  only  difference  in  the  two  cases  is  the  reduced  arrival  rate 
in  the  final  case. 

Redesign  of  Operator  Display  — 

From  the  decomposition  of  operator  tasks  discussed  in  A. 3. 2,  it 
is  apparent  that  button-pressing  sequences  directly  affect  the 
estimates  of  service  time  values.  For  example,  consider  the 
"region  decision"  required  to  generate  the  ADS-1  report  (Fig. 
A-7).  The  operator  must  scan  the  map  to  find  the  appropriate 
launch  site  for  the  event  under  consideration.  The  search  time 
might  be  reduced  if  this  site  were  displayed  with  a  blinking 
symbol.  The  blinking  could  reduce  effective  search  time  from 
3.0  seconds  to  1.0  second,  which  would  produce  approximately  an 
8  percent  reduction  for  the  ADS-2  report  overall. 
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Although  the  examples  cited  above  are  based  on  a  simulated  (and  simpli¬ 
fied)  C3  system,  they  do  suggest  how  sources  of  long  delays  can  be  isolated 
and  design  options  considered  for  more  realistic  C3  environments.  As  illu¬ 
strated  here,  the  analysis  is  done  at  a  level  that  accounts  for  individual 
operator  actions  and  decisions.  Changes  in  procedures  or  the  human-machine 
interface  can  then  be  directly  addressed. 


Queuing  theory  can  provide  the  means  of  integrating  service  and 
arrival  time  estimates  into  performance  predictions  —  but  only 
when  appropriate  data  can  be  collected  from  the  operational 
environment  and  models  are  available  to  describe  human  behavior 
on  tasks  of  a  generic  nature  (e.g.,  scanning  CRT  displays). 


A. 6  REPRESENTATION  BY  PETRI  NETS 

It  is  a  trivial  exercise  to  represent  these  queuing  equations  by  Petri 
nets,  as  discussed  in  Volume  I.  A  more  complex  and  more  representative  exam¬ 
ple  is  given  in  Section  4,  which  provides  a  five-level  Petri-net  decomposition 
of  an  Air  Defense  C3  system. 
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APPENDIX  B 


NORAD  CMC  MWC/CP  LITERATURE  REVIEW 


Documents  furnished  by  AAMRL,  listed  in  Table  B-I,  were  reviewed  and 
assessed  for  material  relevant  to  the  SLBM  scenario.  Tables  B-2  through  B-5 
summarize  high-level  information  gleaned  from  that  review.  Data  voids  were 
identified  in  an  effort  to  specify  areas  where  further  information  was  needed 
to  carry  out  quantitative  analysis  of  human  operator  tasking.  Specific  ques¬ 
tions  were  generated  dealing  with  activations,  terminations,  and  other  time- 
dependent  variables  that  would  affect  execution  of  MWC  and  CP  functions. 

These  questions,  reproduced  as  Table  B-6,  were  intended  as  representative 
issues,  particularly  sensitive  to  effects  of  real-world  circumstances  on  crew 
activities  and  interactions.  Table  B-7  lists  relevant  acronyms. 
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TABLE  B-l.  AAMRL-SUPPLIED  DOCUMENTATION 


NO.  ORIGINATOR  CLASS. 


TITLE 


5W! 


es 

w 

& 

? 

$ 

I 

& 


MITRE 


AAMRL 


NCS  Missile  Warning  Summary 

An  Evaluation  of  Human  Factors 
Engineering  in  the  NORAD 
Missile  Warning  Center 

NORAD  C3  Study:  Command  Post 
Data  Flow 


9  Aug  79 


1  Oct  80 


10  Oct  80 


AAMRL 


Human  Factors  Engineering  in  the 
NORAD  Command  Post 


2  Apr  81 


Integrated  Analysis  Techniques 
Development  and  Applications  of 
IDEF0  to  NORAD  Command  Post  Missile 
Event  Operations 


30  Sep  81 


NORAD 


An  Approach  to  the  Identification 
of  Functions  Significant  to  the 
Performance  of  the  NORAD  Cheyenne 
Mountain  Complex  Mission 

Integrated  Analysis  Techniques 
Development  and  Applications  of 
IDEF0  to  NORAD  Cheyenne  Mountain 
Complex  Operations 

Ivy  League  '82 

NCMC  Critical  Event  Data  Flows 

Critical  Events/Conditions  and 
Mission  Threat  Summary  Report 

NCMC  Functional  Analysis  with 
Conclusions  and  Recommendations 


30  Nov  81 


30  Nov  81 


13  Feb  82 


15  Jul  82 


5  Aug  82 


30  Sep  82 


Integrated  Analysis  Techniques 
(IAT)  for  Application  to  Command, 
Control,  and  Communciations  Systems 


30  Sep  82 


NCMC  Functional  Analysis  with 
Conclusions  and  Recommendations 
(Executive  Summary) 


15  Jan  83 


(continued) 
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TABLE  B-l.  AAMRL-SUPPLIED  DOCUMENTATION  (Continued) 


NO.  ORIGINATOR  CLASS. 


AAMRL 


AAMRL 


AAMRL 


AAMRL 


MITRE 


MITRE 


AAMRL 


TITLE 


NORAD  Command  Post  Replacement 
Phase  1  Report 


28  Feb  83 


Crew  Options  for  a  Mission  Integrated 
NORAD  Command  Post 


14  Jul  83 


Survey  of  Human  Factors  Affecting 
the  ADCOM  Intelligence  Center  (ADIC) 
Watch  Crew 


Design  Considerations  for  NORAD 
C3  Displays 


Functional  Representation  of  the 
ADCOM  Intelligence  Center  with 
NORAD  Command  Post  Interfaces 


Analysis  of  the  CMC  Displays 


NCCS  Functional  Analysis  Charts 
(MITRE  No.  843-3067) 


CSSR  Message  Processing  Requirements 
(MITRE  WP-6731) 


MWC  Operations  ( J 3 1  Operating 
Instruction  55-329) 


Extracts  from  Unclassified  Summary 
of  AMRL  Studies  at  NCMC  (For 
Official  Use  Only) 


15  Jul  83 


30  Sep  83 


15  Nov  83 


13  Apr  84 


15  Jun  84 


Nov  84 


14  Jan  85 


[no  date] 
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TABLE  B-2.  EXTERNAL  DATA  SOURCES 


•  NORAD  Computer  System  (NCS)  and  Displays 

•  Space  Defense  Operations  Center  (SPADOC) 

•  SPADOC  Computation  Center  (SCC) 

•  Air  Defense  Operations  Center  (ADOC) 

•  ADCOM  Intelligence  Center  (ADIC) 

•  System  Control  (SC) 

•  Weather  (WX) 

•  Emergency  Action  Resources 

•  Battle  Staff  Support  Center  (BSSC) 

•  Surveillance  and  Status  Center  (SSC) 

•  USAF  Space  Surveillance  System  NORAD 

•  Space  Detection  and  Tracking  System  (SPADATS) 


TABLE  B-3.  MWC  PHASES  OF  OPERATION  IN  RESPONSE  TO  CRITICAL  EVENTS 

PHASE  1:  React  to  QUICK  ALERT  Indicatlon(s) 

PHASE  2:  Process  Missile  Event  Messages 

PHASE  3:  Assess  System  Confidence 


PHASE  4: 


Indicate  NORAD  Confidence  Assessment  to  CINCNORAD 
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TABLE  B-4.  TEN  GENERIC  MISSILE  WARNING  CENTER  PROCESSES 
(Table  B-l,  No.  2) 

(1)  Monitor  System  Status  and  Performance 

(2)  Monitor  for  Sensor  Warning  Indications 

(3)  Interpret  All  Incoming  Voice  and  Digital  Data 

(4)  Evaluate  Implications  of  Interpreted  Data 

(5)  Decode  Incoming  Data  and  Encode  Outgoing  Data 

(6)  Update  System  Database 

(7)  Report  Key  System  and  Event  Data 

(8)  Coordinate  Critical  Missile  Warning  Functions 

(9)  Maintain  Console  and  System  Configurations 

(10)  Follow  Established  Procedures 


TABLE  B-5.  PROCESSES  FOR  THREAT  WARNING  ASSESSMENT 
(Table  B-l,  No.  15) 

(1)  Receive  Event  Indications 

(2)  Monitor  Sensor  Status 

( 3)  Interpret  Sensor  Status/Capability 

(4)  Verify  Systems 

(5)  Interpret  Event  Indications 

(6)  Confirm  Event  Indications 

(7)  Analyze  Event  Data  (for  Threat  Characteristics) 

(8)  Correlate  Event  Data  (with  Other  External  Data) 

(9)  Formulate  C1 2 3 4 5 6 7 8 9 10 11  Decisions  (with  CINCNORAD) 

(10)  Format  Outputs 

(11)  Transmit/Send 
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TABLE  B-6.  QUESTIONS  ASKED  ABOUT  MWC/CP  ACTIVITIES 


1.  Is  flow  of  activities  correct? 


Where  are  we  likely  to  find  significant  effects  of  reduced  crew  (under 
what  circumstances)? 


Day-to-day  operations 

Contingency 

Crisis 


3.  To  what  extent  does  individual  knowledge/skills/abilities  (KSA)  account 
for  performance  decrements  if  a  given  staff  member  is  absent? 


(Example:  If  we  asked  operations  personnel  what  would  happen  if 

the  MWO  or  EVO  were  not  there,  would  they  say,  "...  it  all  depends 
who  the  person  is  filling  those  roles  —  IAT  RESOURCES  as  opposed 
to  ORGANIZATIONAL  elements.) 


4.  What  specifically  constitutes  an  EVENT? 


Do  multiple  missile  launches  always  count  as  a  single  event?  Under 
what  circumstances? 


What  are  the  implications  for  modeling  single  vs-  multiple  launches 
as  events? 


•  For  Petri  net  modeling. 

•  For  queuing  theory  representations 


5.  To  what  extent  is  message-processing  in  the  CP  like  SIMCOPE?  [It  is 
clear  that  the  MWC  does  not  accumulate  messages  in  the  same  fashion 
as  SIMCOPE.  (Example:  one  message  stream  coming  in  to  a  single  human 
operator. 


How  is  message-processing  Implemented  (what  RESOURCES  are  used  and 
how)?  (Example:  If  phone  lines  are  used,  are  they  auto-dialers? 
If  viewgraphs  are  put  up  on  CCTV,  how  is  that  done/by  whom,  how 
long  do  such  tasks  take  to  complete?) 


•  In  MWC 

•  In  CP 


How  are  messages  sent  out  of  the  NCMC? 


How/to  whom  does  NCS  broadcast? 


(continued) 
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TABLE  B-6.  QUESTIONS  ASKED  ABOUT  MWC/CP  ACTIVITIES  (Continued) 


7.  Assuming  that  the  interval  between  the  first  message  leaving  NCMC  and 
the  last  one  is  a  relevant  index  of  (CINCNORAD?)  performance, 

How  long  does  it  take  to  get  all  messages  out? 

How  many  messages  are  involved? 

If  confirmation  is  requested,  is  it  requested  for  each  message  (or 
part  thereof),  or  for  all  messages  at  the  same  time? 

How  do  "altered"  messages  get  sent  out  of  NCMC  (i.e.,  messages  that 
get  updated)? 

What  triggers  update  (under  what  circumstances  are  messages  changed)? 
What  conditions  does  it  take  to  change  DEFCON  levels? 

•  How  are  DEFCON/LERTCON  levels  defined? 

•  Are  there  any  other  levels/scales  used  to  describe 
real-world  status? 

8.  Is  it  the  case  that  TW  activities  take  place  for  less  than  15  launches 
. , .  and  AA  for  more  than  15  launches? 

During  A A,  are  the  two  message  formats  the  only  ones  that  get  sent  out? 
Or  are  they  part  of  the  TW  phase? 

9.  When  CINCNORAD  requests  confirmation  or  makes  information  requests  via 
the  CD  to  MWC ,  how  is  the  querying  carried  out  (e.g.,  beige  loop,  CRT, 
written  communications,  etc.)? 

What  constitutes  typical  queries  (viz.,  for  each  message  format  ... 
what  questions  would  be  asked  to  confirm  alternative  or  options)? 

What  is  the  impact  on  ongoing  MWC  operations  when  these  questions  are 
conveyed?  How  much  time  does  it  take  to  answer  them? 


TABLE  B-7 .  LIST  OF  ACRONYMS 


AC 

Assistant  for  Communication 

ACD 

Assistant  Command  Director 

AD 

Assistant  for  Displays 

ADCOM 

Air  Defense  Command 

ADIC 

ADCOM  Intelligence  Center 

ADOC 

Air  Defense  Operations  Center 

BS 

Battle  Staff 

BSSC 

Battle  Staff  Support  Center 

CCT 

Command  and  Control  Technician 

CD 

Command  Director 

CDT 

Command  Director  Technician 

CINC 

Commander-in-Chief 

CINCLANT 

Commander-in-Chief  Atlantic 

CINCPAC 

Commander-in-Chief  Pacific 

CINCSAC 

Commander-in-Chief  Strategic  Air 

Command 

CP 

Command  Post 

CSS 

Command  Systems  Segment 

GDC 

Graphic  Display  Console 

GDU 

Graphic  Display  Unit 

HQSAC 

Headquarters  Strategic  Air  Command 

LCl/DO 

Launch  Correlation  Display  Unit 

Officer 

MEBU 

Minimum  Essential  Back-Up  Unit 

MWC 

Missile  Warning  Center 

MWO 

Missile  Warning  Officer 

MWS 

Missile  Warning  Supervisor 

MWT 

Missile  Warning  Technician 

NCMC 

NORAD  Cheyenne  Mountain  Complex 

NCS 

NORA D  Computer  System 

NID 

Non-Interactive  Displays 

NMCC 

National  Military  Command  Center 

NORAD 

North  American  Aerospace  Defense 

Command 

SATPACK 

Satellite  Package 

see 

SPADOC  Computation  Center 

SPADOC 

Space  Defense  Operations  Center 

TTY 

Te  letype 

TUDE 

Teletype  Users  Data  Entry 

TW/AA(TWAA) 

Threat  Warning  and  Attack  Assessment 
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APPENDIX  D 


PRELIMINARY  NORAD  MWC/CP  ORGANIZATION  FRAMES 


In  this  appendix  it  is  shown  how  the  frame/slot  data  organization  con¬ 
cept  from  artificial  intelligence  can  be  used  to  represent  the  NORAD  Missile 
Warning  Center /Command  Post  (MWC/CP)  organizational,  process,  resource  and 
goal  interrelationships.  Figure  D-l  shows  the  lines  of  authority  and  respon¬ 
sibility  among  the  various  organizational  elements. 

Note  that  each  frame  represents  a  separate  organizational  element  in  the 
MWC.  The  slots  in  a  frame  represent  the  processes  for  which  that  element  is 
responsible,  the  primary  supporting  resources ,  and  the  goal  or  objective  to  be 
achieved. 
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ORGANIZATION  NAME: 


GOAL: 


PROCESS: 


PARENT  ORGANIZATION: 


ORGANIZATIONAL  ELEMENTS : 


INPUTS: 


OUTPUTS: 


NORAD  Command  Post 

Provide  Threat  Warning  and  Attack 
Assessment  (to...) 

Aerospace  Surveillance  and  Situation 
Assessment 


CINC  NORAD,  Daily  Duty  Staff,  Battle  Staff 

MWC  Missile  Warning  Center 

SPADOC  Space  Defense  Operations  Center 

ADOC  Air  Defense  Operations  Center 

ADIC  Air  Defense  Command  Intelligence 

Center 

BSSC  Battle  Staff  Support  Center 

TW/AA  Messages* 


■'Messages  leaving  the  NCMC  CP  are  dispatched  to  members  of  an  address  list. 
The  contents  of  that  list  may  vary;  the  names  of  the  variants  and  rules  for 
list  selection  are  needed. 
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ORGANIZATION  NAME: 


GOAL: 

PROCESS: 

PARENT  ORGANIZATION: 
ORGANIZATIONAL  ELEMENTS: 


INPUTS: 


Daily  Duty  Staff 

Peacetime  Operations  Fully  Supported 
Monitor  for  Threat  Detection 
NORAD  CP 

CD  -  Command  Director 

CDT  -  Command  Director  Technician 

ACD  -  Assistant  Command  Director 

AC  -  Assistant  for  Communications 

AD  -  Assistant  for  Displays 

CCT  -  Command  and  Control  Technician 


OUTPUTS: 


Same  as  Parent 


ORGANIZATION  NAME: 


GOAL: 

PROCESS: 

PARENT  ORGANIZATION: 
ORGANIZATIONAL  ELEMENTS: 


INPUTS: 


Battle  Staff  (BS) 

Wartime  Operations  Fully  Supported 


Provide  Support  to  CINC  NORAD 
NORAD  Command  Post  (CP) 


CINC  -  Commander-in-Chief 

D/CINC  -  Deputy  Commander-in-Chief 

NCOC  -  NORAD  Computer  Operations  Center 

Commander 

CMDR  ASST  -  Assistant  NORAD  Computer 

Operations  Center  Commander 
EAO  -  Emergency  Actions  Officer(s) 

VCMDR  ADCOM  -  Vice  Commander,  Air  Defense 

Command 

J2  -  Intelligence 
J3  -  Operations 
J4  -  Logistics 
J6  -  Communications 


OUTPUTS: 


ORGANIZATIONAL  ELEMENTS: 


GOAL: 


PROCESS: 


PARENT  ORGANIZATION: 


SUBORGANIZATION: 


INPUTS: 


OUTPUTS: 


PRIMARY  RESOURCES: 


RELATED  RESOURCES: 


Command  Director  (CD) 

CP  Functions  Executed  Successfully 

1)  Supervise  and  Direct  NCMC  Operations 

2)  Represent  CINCNORAD  in  his  absence 


Daily  Duty  Staff 

Messages  or  Requests  to/from  CINCNORAD 
Specific  Digital  Data 

Voice  Communication  (Secure/Unsecure  and 
External/Internal) 

Non-Vocal  Signals 
Threat  Panel  Displays 
Large  Screen  Displays 

Directives  to  CP  Staff;  inquiries;  reports 
Digital  Data 
Voice  Communication 
Non-Vocal  Signaling 
Other  Keyboard/Switch  Actions 

1)  CD  Console 

2)  CP  Staff 

3)  NCMC  Support  Centers 

Regulations/Directives 

Doctrine/Orders 

Operating  Instructions/Technical  Orders 
Procedures  Guides/Handbooks 
Checklists/Message  Formats 
Training  Courses/Exercise  Materials 


WWW 
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ORGANIZATIONAL  ELEMENT: 


GOAL: 


PROCESS: 


PARENT  ORGANIZATION: 


SUB  ORGANIZATIONS: 


INPUTS: 


OUTPUTS: 


RESOURCES: 


Command  Director  Technician  (CDT) 

All  Messages  Dispatched 

Authenticator  Control  and  Alert 
Message  Dissemination 

Daily  Duty  Staff 
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ORGANIZATIONAL  ELEMENT: 
GOAL: 

PROCESS: 

PARENT  ORGANIZATION: 

SUB  ORGANIZATIONS: 
INPUTS: 

OUTPUTS: 

RESOURCES: 


Assistant  Command  Director  (ACD) 
CD  Supported 

Backup  CD  and  Implement  Emergency 
Action  Procedures 

Daily  Duty  Staff 

N/A 


ORGANIZATIONAL  ELEMENT:  Assistant  for  Communication  (AC) 

GOAL:  Personnel  Recalled,  Events  Tracked 

and  Log  Maintained 

PROCESS:  Establish  JCS  Alerting  Network 

Communications  and  Record  Activities 

PARENT  ORGANIZATION:  Daily  Duty  Staff 

SUB  ORGANIZATIONS:  N/A 

INPUTS: 

OUTPUTS: 


RESOURCES: 


ORGANIZATIONAL  ELEMENT: 


Assistant  for  Displays  (AD) 


GOAL: 

PROCESS: 

PARENT  ORGANIZATION: 
SUB  ORGANIZATIONS: 
INPUTS: 

OUTPUTS: 


CP  Properly  Briefed,  Authentication  System 
Inventoried  and  Log  Maintained 

Organize  and  Maintain  Non-Coraputer 
Information  Base 

Daily  Duty  Staff 

N/A 


RESOURCES: 
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ORGANIZATIONAL  ELEMENT: 
GOAL: 

PROCESS: 

PARENT  ORGANIZATION: 
SUBORGANIZATION: 


INPUTS: 


OUTPUTS: 

RELATED  RESOURCES: 


Missile  Warning  Center  (MWC) 

Missile  Event  Data  Reported 

Monitor  System  Status  and  Process 
Site  Messages 

NCMC 

MWO  Missile  Warning  OfficeL 

EVO  Events  Verification  Officer 

(formerly  Events  Analysis  Officer) 
MEBU  Technician 
(formerly  CCPDS  Officer) 

MWS  Missile  Warning  Supervisor 

(formerly  Superintendent  NCS) 

MWT  Missile  Warning  Technicians  (two) 

(formerly  E/W  Hemisphere  Monitors) 


GDU  Changes 

Terrainet  Printer  Output 
MEBU  Console  Changes 
Tactical  Display  Panel  Changes 
Auditory  Alarms 
Telephone  Messages 

TUDE  Equipment 
TTY  Messages 
Telephone  Messages 

Maps 

Checklists 
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ORGANIZATIONAL  ELEMENT: 


MEBU  Technician 


ORGANIZATIONAL  ELEMENT: 

GOAL: 

PROCESS: 

PARENT  ORGANIZATION: 

SUBORDINATE  ORGANIZATIONAL  ELEMENTS: 
INPUTS: 


Missile  Warning  Supervisor  (MWS) 

Directives  Complied  with  for  All  Actions 
Accomplished 

Supervise  MWT  Crew  and  Accomplish 
Assigned  Activities 

Missile  Warning  Center 

Missile  Warning  Technicians  (Two) 


OUTPUTS: 

RESOURCES: 


ORGANIZATIONAL  ELEMENT: 
GOAL: 

PROCESS: 

PARENT  ORGANIZATION: 
SUPERVISORY  ELEMENT: 

SUB  ORGANIZATIONS: 
INPUTS: 

OUTPUTS: 

RESOURCES: 


Missile  Warning  Technician  (MWT) 

Database  Maintained  and  Communications 
Accomplished 

Operate  GDU  Console  and  Backup 
MEBU  Technician 

Missile  Warning  Center 

MWS 

N/A 
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